Incident report and criticality levels

This is not the post-mortem. This is the document that exists while something is broken, and its job is to keep everyone informed without interrupting the people fixing it.

Keeping them separate matters. A single document that tries to do both gets written badly under pressure and then abandoned once the pressure lifts.

Criticality levels

The point of a written scale is that “urgent” stops being a property of how a request is phrased and becomes a property of the request. Everything below is a reasonable default — the specific windows should match your business, but they must be written down before you need them.

C1 — Critical
  Production unavailable, data at risk, revenue directly affected,
  or a legal or regulatory obligation.
  Response: immediately, same day, may interrupt planned work.
  Requires: named owner, stakeholder notification, post-mortem.

C2 — High
  Major function broken or degraded with no workaround, or a defect
  blocking a committed release.
  Response: within the current iteration.
  Requires: named owner.

C3 — Medium
  Function impaired with a workaround, or a defect with limited reach.
  Response: next iteration, prioritised normally.

C4 — Low
  Cosmetic, minor inconsistency, or an improvement request.
  Response: scheduled, no commitment implied.

Two rules stop the scale from decaying:

Only C1 may interrupt committed work. If C2 can also interrupt, everything becomes C2 within a month and you are back where you started.

Classification is not self-service. The person raising an issue proposes a level; someone accountable for the queue confirms it. Without that, urgency reflects the requester’s seniority rather than the impact.

The template

# Incident: [what users are experiencing]

Status:        investigating / identified / mitigating / monitoring / resolved
Criticality:   C1 / C2
Started:
Owner:
Comms owner:   (for C1 — should not be the same person)

## Current impact
What is affected, who notices, and what still works.
State what still works explicitly — it prevents a wider panic than warranted.

## Working theory
What we currently believe, marked clearly as belief rather than fact.
Update or strike out as it changes; do not silently rewrite.

## Actions taken
  HH:MM  What was done, and what effect it had (including "no effect").

## Next update
A time. Always a time.

Why “next update: a time” is the most important line

An incident channel without a stated next update generates a second incident: everyone with an interest starts asking for status, and the people fixing the problem spend their attention on answering instead of on the problem.

Committing to an update every thirty minutes — even when the update is “no change, still investigating” — costs one message and removes that entire class of interruption. For a C1, splitting the owner and the comms owner does the same thing structurally.

Why “what still works” is in the template

The instinct during an incident is to describe the breakage. But the people receiving the report are making decisions — whether to pause a campaign, whether to notify a partner, whether to escalate — and those decisions need the boundary of the problem, not just its centre.

Handover

Incidents outlast shifts. If yours can run long, the report is the handover artifact, which is the other reason the working theory must be written down rather than held in the head of whoever is awake.

State explicitly: current status, what has been ruled out, what is untested, and who has been told what. “What has been ruled out” is the field that saves the most time and is skipped the most.