- 01Read the incident. From the webhook payload, capture the incident ID, title, service, urgency, and assignee, then retrieve the incident and its alerts from PagerDuty for the triggering details. Stop if the service or urgency is out of scope.
- 02Check for a duplicate. Search Jira for an open incident ticket that already references this PagerDuty incident ID. If one exists, link to it and do not open another.
- 03Open the thread. Post one message in the Slack incident channel with the title, service, urgency, assignee, start time, the PagerDuty link, and the most relevant alert details, and use that message's thread for everything that follows.
- 04Open the ticket. Create a Jira issue in the configured project with the incident ID, links to PagerDuty and the Slack thread, and the alert details, then post the ticket link in the thread.
- 05Gather context. Pull recent change events PagerDuty associates with the incident and any related incidents on the same service, and post them in the thread as possible leads, clearly marked as unconfirmed.
- 06Draft the first update. Write a short stakeholder status update: what is affected, what is known, what is being done, and when the next update will come. State only what the incident data shows.
- 07[Approval gate] Review the stakeholder update before it is posted anywhere outside the incident thread.
- 08Post the approved update. Add the approved text as a status update on the PagerDuty incident and post it in the thread.
Never acknowledge, resolve, reassign, or escalate the incident in PagerDuty. Humans run the response.
Never post a cause as fact. Change events and related incidents are leads until an engineer confirms them.
Do not post stakeholder updates without the approval gate clearing.
Redact secrets, tokens, and customer data that appear in alert payloads before posting them to Slack or Jira.
One incident gets one thread and one ticket. If you cannot tell whether a ticket already exists, say so in the thread instead of creating a second.