The incident page
At the top: the priority, the key and the status, the title, the commander, the affected units and how long it has lasted. Open P1 and P2 incidents have a coloured banner.
The status is a row of steps:
New → Investigating → Identified → Monitoring → Resolved → Closed
Any open step → On hold: while it waits for a supplier, the customer or a change; taken off hold, it goes on
Resolved → Investigating: a step back reopens it, until it closes
| Status | Means |
|---|---|
| New | Declared; nobody has taken it yet. |
| Investigating | Something is wrong; finding out what. |
| Identified | The cause is known; a fix is on its way. |
| Monitoring | A fix is in place; watching that it holds. |
| Resolved | Over. It can still be reopened. |
| Closed | Final: after that only notes and the review can be added. |
Click a step to move there. Put on hold (at the top) asks what it waits for (a supplier, the customer, a planned change, something else) and stops the resolve clock; Take off hold starts it again. Resolved asks for a resolution (Fixed, Workaround, No fault found …, as your admin set them) and what was done. A resolved incident closes by itself after three days (or what your admin set); until then a step back reopens it, and Closed closes it at once.
[!NOTE] While an incident is on hold, its resolve clock stops, so a supplier's delay doesn't count against your targets.
Waiting for the customer: an incident on hold for the customer reminds the commander after three days, and is resolved by itself four days later with "No response from the customer" (both numbers in the settings).
The side panel is in the same order as on a case (the side panel). First Incident: the status, the priority (or impact and urgency), the commander and how many linked cases get updates; then Targets, and for a major incident its roles. Then Service (the service, category and units) and, with the Status Page plugin, Status page. Custom properties, Details (the times and who declared it) and the summary are folded at the bottom. … → Edit details… changes the title, summary, affected units and times; Delete incident is there too, with the Delete incidents permission.
Timeline
Everything that happened to the incident, newest first: declared, status and priority changes, holds, missed targets, the commander, category, units, links, notes, updates sent to requesters, the status page, closing and the review. Add note puts what you know now on the timeline (Markdown; ⌘/Ctrl + Enter adds it). Notes are internal: requesters never see them.
Linked cases
The cases this incident causes, with their status. Link one by its reference here, from the case, or many at once from the inbox (below). A case must be in the incident's organization and one you can see. × unlinks it. A case marked "gets no updates" is closed, merged into another or held for review.
Review
Once the incident is resolved or closed, Write the review: a post-incident review (often called a post-mortem) in Markdown, starting from a template (summary, timeline, cause, what went well, what you'll change). Keep it blameless: what happened and what changes, not who.
- Facts, above the review, are what the incident already knows: when it started, was detected, taken and resolved, how long each step took, the highest priority it had, how many units and linked cases it touched, the updates sent to requesters, and the targets missed.
- Cause: pick what caused it from your organization's list (a change or deploy, configuration, capacity, a supplier …; your admin sets the list). Reports count resolved incidents by cause.
- Insert timeline, while you write, fills the review's Timeline section from the incident's own timeline: the status and priority changes, who took command, notes (their first line), updates sent and missed targets, oldest first. It replaces what the section held; change the text as you like afterwards.
- Summary for customers: what happened, why, and what changes, written for the people who were affected (often called an RFO, reason for outage). Write the summary starts from a short outline with the times filled in; Save draft keeps it, and Send… sends it like an update to the requesters of the linked cases (and the status page of a public incident). The incident keeps the text that was sent, and when.
- The cause, for good: with Problem Management on, a card under the review lists the problems linked to the incident, with Open problem to open one from the review: the incident's cause and its timeline go along. Your admin can ask for a problem on every major incident; then the card says so while none is linked. It never stops the incident from closing.
Process controls
Your admin can set process controls on incidents: a second person must have worked on it, a data property must be filled in, the resolve target must be met, or the review must be written. An enforced control stops the incident from being resolved or closed until it is met, and says which control and what is missing. A checked one lets it go ahead, and records whether it was met.