Console d’incident majeur avec export de la revue post-incident
Run the worst hour of the month from one screen: a live clock, named roles, a timestamped timeline and ready-to-send updates. Then leave with a post-incident review you can put in front of the board.
- Live incident clock
- Board-ready PIR
- Fonctionne dans votre navigateur
A post-incident review needs four times read from one timeline: time to detect, to declare, to mitigate and to resolve. In this tool's worked example, a hypothetical Sunday-morning P1 on UAE store card payments, impact began at 09:12, detection took 8 minutes, mitigation 53 minutes and resolution 2h 28m. Updates went out every 30 minutes, a common starting point for a P1.
The incident
Start the clock when you declare. Everything saves in this browser as you type; nothing is sent anywhere.
Roles
One name per role. The Incident Manager runs the incident and does not fix it; the Scribe keeps the timeline and nothing else.
Timeline
Type what happened, then press its type: the entry is stamped now. Every time stays editable, and the first detection, mitigation and resolution entries set the key times.
Stakeholder messages
Filled from the fields above; anything still missing shows in [brackets]. Copy, check, send, then log it as a Comms entry so the next update is timed from it.
Update cadence: every 30 minutes for a P1 and every 60 minutes for a P2. That is a common practice starting point, not a standard; use your own procedure's cadence where it has one.
Initial notification
Update
Resolution notice
Post-incident review
The review builds itself from the incident. Add the contributing factors and the actions, then print it or download it as Markdown.
Actions
One owner and one due date for each. Actions without them are flagged in the review.
What a good post-incident review contains
A review that a board or an audit committee will accept is short, factual and ends in actions someone owns. Use this list before you send it.
- Blameless. Describe what the system, the process and the information available allowed, not who slipped. People who expect blame stop writing honest timelines.
- Impact in business terms. Who could not do what, for how long, and where. “Stores took cash only for 53 minutes” lands; “gateway errors elevated” does not.
- One timeline, with sources. Alerts, decisions and messages in time order. Detection and declaration are separate moments; the gap between them is often the most useful number in the review.
- Contributing factors, not one root cause. Major incidents usually need several conditions at once. List each, then test them in the root cause analyser.
- Actions with one owner and a due date. Each action traces back to a factor. An action owned by a team, or with no date, is an intention, and the console flags it.
- Agreed within days, reviewed later. Hold the review while memories are fresh, then check at the next service review that the actions closed.
Méthode et propriété
Key times are read from the timeline you keep: time to detect runs from the impact start to the first detection entry, time to declare from detection to declaration, and times to mitigate and resolve from the impact start (or from detection when the start is unknown) to the first mitigation and resolution entries. The update cadence is a common practice starting point, not a standard. Nothing is sent anywhere; the incident is kept in this browser until you reset it.
Les formules utilisées ici sont des méthodes standard et publiées. L’implémentation, l’interface, les textes, la logique des constats et les chiffres de référence sont une œuvre originale d’ITSM Compass. Les résultats sont des estimations, pas un avis professionnel. Voir les conditions d’utilisation.
© 2026 ITSM Compass. Tous droits réservés.
Questions
Is anything about my incident sent anywhere?
No. The console runs in your browser and sends no incident data anywhere. The incident is kept in this browser's local storage so a refresh or a dropped laptop lid does not lose the timeline, and Reset deletes it. Export the JSON file if someone else needs to pick it up.
Why 30 minutes for P1 updates and 60 for P2?
It is a common practice starting point, not a standard. What matters more is that the cadence is announced and kept: stakeholders who know when the next update is coming stop chasing the bridge. Use the cadence in your own major incident procedure if it says something different.
What is the difference between mitigated and resolved?
Mitigated means the impact has stopped, often through a workaround such as a failover or a rollback. Resolved means the service is back to its normal state and the workaround is no longer carrying it. Many incidents spend hours between the two, which is why the review records both.
Who should be the Scribe?
Someone who is not fixing anything. The Scribe's only job is the timeline: what was seen, decided and done, and when. A Technical Lead who also keeps the log will stop logging exactly when it matters most.
Can I fill the times in afterwards?
Yes. Every time in the timeline can be edited, and the durations and the review update as you change them. Reconstructing from chat, alerts and ticket history afterwards is normal; mark anything you are unsure of in the entry text.
How does the hand-off to the root cause analyser work?
Each contributing factor you list becomes a candidate cause in the analyser, and the impact start becomes its first-seen time. It passes through this tab's session storage, and the analyser deletes it as soon as it reads it.
Major incidents that keep repeating?
A fractional service delivery manager can set up the major incident procedure, the roles and the review cadence, and make sure the actions close.