Incident Response Flowchart: From First Alert to Postmortem

At three in the morning, nobody reads a ten-page incident policy. The on-call engineer needs to know four things fast: is this real, is it an incident, who else needs to know, and what to do first. A one-page flowchart answers those questions in the order they come up, and it is the part of the policy people actually follow.

This post builds an incident response flowchart for an engineering team running a production service: triage, the criteria for declaring an incident, severity and roles, mitigation, and the postmortem that closes the loop. It ends with drawing advice that keeps a flowchart usable under stress.

What the flowchart has to decide

An incident process is a series of decisions with a few long-running activities between them. The decisions belong on the chart, written as questions with labeled answers:

• Is the alert real and actionable? If not, the problem is the alert.
• Is it an incident? If not, it is ordinary work with a ticket.
• How severe is it? Severity decides who is paged and who is told.
• Is the service restored? If not, try the next mitigation or escalate.

Everything else, such as how to roll back a deployment or fail over a database, belongs in runbooks the chart links to.

When to declare an incident

Declaring is the step teams hesitate over, and the hesitation is expensive. The chapter on managing incidents in Google's SRE book argues for declaring early: it is better to declare, find a simple fix and close the incident than to start the process hours into a growing problem. The team in that chapter declares when any of these is true:

1. A second team is needed to fix the problem.
2. The outage is visible to customers.
3. The issue is unsolved after an hour of concentrated analysis.

Put your own criteria on the chart, next to the decision. Clear criteria remove the social cost of declaring.

Roles

The same chapter describes a structure based on the Incident Command System. Even a small team benefits from naming the roles, because one person doing all of them is the most common failure:

The incident commander also keeps a living incident document, and hands off explicitly at the end of a shift: the outgoing commander states the handoff and waits for acknowledgment.

Incident management skills fade when they are not used. The same chapter suggests applying the framework to operational changes that span teams or time zones, and role-playing past incidents, so the process is familiar before the next real one. Walking a new on-call engineer through the flowchart with an old incident is a cheap way to start.

Severity levels

Severity definitions vary by company, so treat these as an example and write yours on the chart:

The flowchart, step by step

1. Acknowledge and triage. When the alert fires, acknowledge it so the page stops escalating, then look at scope and impact.
2. Real and actionable? A false or unactionable alert is tuned or deleted, then closed.
3. Is it an incident? Apply the criteria. If not, handle it as normal work with a ticket.
4. Declare. Name the incident commander, open a channel and the incident document.
5. Severity. For SEV-1 and SEV-2, a communications lead posts on the status page and sends regular updates.
6. Mitigate first. Roll back, fail over, disable the feature flag or shed load. The SRE book's first priority is to stop the bleeding, restore service and preserve the evidence; root cause comes later.
7. Restored? If not, try the next mitigation or escalate, and loop.
8. Resolve. Confirm with metrics, keep watching, and hand the system back to normal operations.
9. Postmortem and action items. Write a blameless postmortem, review it, and close the incident when the action items are tracked.

How to read it:

• Yes goes right, No goes down. Every decision uses the same convention, so the main path steps right and the early exits drop down.
• Left, first response. The alert is acknowledged and triaged. Alerts that are not real or actionable, and events that are not incidents, end at Done.
• Third column, the incident. It is declared, checked for severity and mitigated. SEV-1 and SEV-2 add a communications lead on the right.
• The loop. "Service restored?" sends you back to mitigation until the answer is yes.
• Right column, closing. Resolve, write the blameless postmortem, and close when the action items are tracked.
• Notes hold the declaration criteria and the severity levels, so nobody has to open another document.

The postmortem closes the loop

The SRE book's chapter on postmortem culture lists common triggers, such as user-visible downtime or degradation beyond a threshold, and data loss of any kind. A postmortem is blameless when it looks for contributing causes in systems and processes without blaming people; otherwise, people stop raising problems. Draw the postmortem on the chart as a document with an owner and a deadline, and do not mark the incident closed until its action items are tracked.

Security incidents need more than this chart: evidence preservation, legal and regulatory steps, and often a separate team. NIST SP 800-61 Rev. 3, published in April 2025, is the usual reference. Link a security branch to that process instead of improvising one.

Drawing advice for flowcharts under stress

• One start, clear ends. Every path should end somewhere, even if that is "Done".
• Decisions as yes-or-no questions, with both exits labeled, and Yes and No leaving from the same sides every time.
• Make loops explicit. "Try the next mitigation" is a loop, not a footnote.
• Fifteen shapes or fewer. Details go into runbooks linked from the steps.
• Show where responsibility changes. For a version with lanes per role, start from the cross-functional flowchart template.
• Keep it where on-call engineers look. Link or embed the live diagram in the runbook rather than pasting a screenshot.

If your process involves many teams and formal hand-offs, a BPMN diagram can model it more precisely; for on-call use, a flowchart is easier to follow.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. From the Flowchart pack, add a Terminator for the start and for each end, a Process for each step and a Decision for each question.
3. Add a Document for the postmortem.
4. Connect the shapes. The Decision shape marks Y on its right corner and N on its bottom corner, so draw Yes to the right and No downward, label both, and route the "not restored" exit back to mitigation.
5. Add Core Note nodes with your declaration criteria and severity levels.

The example uses 15 diagram nodes, within the Free plan. The flowchart maker page shows the other shapes and the swimlane layout.

FAQ

Who should own the incident response flowchart? The team that runs the on-call rotation. Review it after every incident where someone did not know what to do next.

Should every alert be an incident? No. Most alerts should be handled as ordinary work. Declare when your criteria are met, and declare early when in doubt.

Do I need an incident commander for small incidents? Someone has to hold the overall picture. In a small incident the on-call engineer is the commander, and saying so out loud prevents two people from fixing the same thing in different ways.

When should the postmortem be written? Soon, while details are fresh. Set a deadline your team can keep, put it on the chart, and track the action items.

Should the flowchart include security incidents? Add a branch that hands them to your security incident process. It has different steps, such as evidence preservation and legal review.

Start free — one seat, no credit card.