Turn Statuspage incidents into support briefs and ticket notes

When my Statuspage status page publishes a new incident or posts a new update to an existing incident, fire a webhook into this workflow so my support team is armed before the tickets pile up. I will add a webhook subscriber on my status page pointing at this workflow's webhook URL, so Statuspage posts to it on incident updates and component status changes.

Start by taking the incident id out of the webhook payload and calling the Statuspage "Get an incident" action to pull the full record. I want the incident name, status, impact level, the public status page shortlink, the affected components with their current statuses, and the body of the most recent entry in the incident updates list. Always work from this fetched detail rather than the webhook payload alone, because the payload is only a summary.

Skip scheduled maintenance entirely. If the incident is a scheduled maintenance rather than a live incident, meaning its status is scheduled, in_progress, verifying or completed, or its impact is maintenance, stop the workflow immediately and do nothing else. Routine maintenance windows should never reach the support queue.

For every real incident that gets past that check, write two things. First a short plain-language brief: what is broken in customer terms, which components or features are affected, the current status, roughly when it started, and what the latest update actually says. Keep it to a few sentences and strip out internal jargon. Second a suggested customer-facing reply of about three or four sentences that acknowledges the problem, confirms we are aware and actively working on it, and points to the status page link. Do not promise a specific fix time unless the latest incident update commits to one.

Post both into our support channel using the Slack Bot "Send a Message" action. Lead with the incident name, impact level and status, then the brief, then the suggested reply under a clear label so agents can copy it straight out without editing around it.

Only run the next step for incidents whose impact is major or critical. For minor incidents, stop after the Slack message has been posted.

For major and critical incidents, use the Zendesk "Search Tickets" action to find open tickets created in the last few hours, roughly the last four, that describe the same symptoms or name the affected components. Build the search terms from the incident itself: the affected component names, the product area, and the symptom words from the incident title and latest update such as errors, timeouts, cannot log in, or slow loading. Restrict the search to tickets that are still new, open or pending. Then read the results and use your judgement about which ones genuinely describe this outage. Do not force a match on tickets that are clearly about something else.

For each ticket you decide is a genuine match, use the Zendesk "Update Ticket" action to attach an internal note, never a public reply. The note should name the incident, link the status page shortlink, summarize which components are affected and the current status, and include the suggested customer-facing reply so the agent handling that ticket can send it without rewriting it. Do not change the ticket status, assignee, priority or tags. A human decides when the customer actually gets a reply.

Finish by posting a short follow-up message in the same support channel saying how many tickets were matched and annotated, with their ticket numbers. If nothing matched, say so plainly and leave the brief standing so the team is still prepared for tickets that come in next.