--- title: "Incident Management Workflow | Orangescrum" description: "Run an incident from first report to resolved, with the follow up actions actually tracked. Severity levels, roles, the timeline." canonical: https://www.orangescrum.com/use-cases/incident-management --- # Incident Management Workflow | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Use cases](/use-cases) / Incident management Use case # Incident Management Where the _Follow Up Actually Happens_ Most teams handle the incident itself reasonably well. What they lose is the eight actions agreed in the postmortem, which is why the same incident happens again in March. Available in[Cloud](/pricing "Cloud - included")[Self-Hosted](/self-hosted "Self-Hosted - included")Open Source [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_incident-management)[Book a Demo](https://calendly.com/orangescrum) Runs on Cloud and Self-Hosted · Microsoft Teams integration is Self-Hosted only ## The scenario At nine forty on a Tuesday, checkout starts failing. Support sees tickets, engineering sees an alert, and for the next twenty minutes three people investigate the same thing without knowing it. It is fixed by eleven. Two weeks later somebody asks what the follow up actions were, and nobody can find them. Orangescrum is not your pager and does not replace your alerting. It is where the incident record, the communication, and above all the follow up work live. Runs Whenever something breaks Typical span Hours to resolve, weeks to close out Start from Bug Tracking template Owner Incident commander, named per incident Who is involved ## Who is _involved_ One person is in charge. That is the single most important rule. | Role | What they own | What they see in Orangescrum | | Incident commander | The decisions, the timeline, and who does what | The incident record and every task hanging off it | | Responder | The investigation and the fix | Their assigned tasks and the running timeline | | Communications lead | Telling customers and internal stakeholders what is happening | The incident status and the affected ticket list | | Support | The customer facing queue and linking tickets to the incident | Tickets grouped against the incident, so one update covers all of them | | Engineering manager | Escalation and pulling in more people | The incident board and the team's current sprint | The workflow ## Nine steps from _alert to closed out_ The last two are the ones teams skip, and they are the reason it happens again. 1. 1 ### Agree the severity levels before anything happens Write down what each severity means and what each one obliges you to do. Severity one wakes people up, severity three waits until Monday. Deciding this during an incident is how you get it wrong. Carried by[Wiki](/wiki-management) 2. 2 ### Raise one incident record, immediately The first person who sees it creates the record. One record, whatever channel the report came from, so three people do not investigate the same thing separately. - Support tickets get linked to the incident rather than answered individually - The record is the single source of truth for the rest of the incident Carried by[Bug and issue tracking](/bug-and-issue-tracking)[Ticketing](/ticketing-software) 3. 3 ### Name an incident commander One named person, on the record, who makes the calls. They do not have to be the most senior engineer, and it is usually better if they are not, because their job is coordination rather than debugging. Carried by[Task management](/task-management) 4. 4 ### Keep the timeline as you go Every finding, every action, and every decision goes on the incident record as a comment with a timestamp. Nobody can reconstruct this afterwards, and the postmortem is worthless without it. - Mention people on the record rather than messaging them separately, so the context stays in one place - Self-hosted teams can push updates into a Microsoft Teams channel as they happen Carried by[Mentions](/mention)[Microsoft Teams](/integrations/microsoft-teams) 5. 5 ### Split investigation from communication The people fixing it should not also be writing customer updates. Give the communications lead the update tasks on a fixed cadence, so responders are not interrupted every ten minutes to be asked for a status. Carried by[Collaboration](/project-collaboration-software) 6. 6 ### Make the incident statuses match reality Investigating, identified, mitigating, monitoring, resolved. These are not the same as a defect flow, and using the wrong statuses means the board does not tell you anything at a glance. Carried by[Custom status workflow](/custom-status-workflow) 7. 7 ### Mitigate first, fix properly second Restoring service and fixing the root cause are two different pieces of work. Close the incident when service is restored, and raise the proper fix as its own defect so it goes through normal prioritisation. Carried by[Bug and issue tracking](/bug-and-issue-tracking) 8. 8 ### Run the postmortem within a week While people still remember. Go through the timeline you kept, and produce actions rather than blame. Anything that does not have an owner and a due date is not an action, it is a wish. Carried by[Wiki](/wiki-management)[Task management](/task-management) 9. 9 ### Put the actions in the backlog and chase them This is the step everybody skips. Each postmortem action becomes a real task with an owner and a due date, linked back to the incident, and it gets reviewed monthly with the rest of the backlog. - Report on how many postmortem actions are still open, by age - An action that is six months old is a decision not to do it, so close it honestly Carried by[Advanced reporting](/advanced-reporting)[Reports and analytics](/project-reports-analytics) Set it up ## Build it _on Monday morning_ Around forty minutes, and best done when nothing is on fire. 1. 1Create an incidents project from the Bug Tracking templateIt opens on a board, which is the right view for a queue where you want to see status at a glance. 2. 2Set the incident statusesInvestigating, identified, mitigating, monitoring, resolved. Add them from the board or the status workflow page. 3. 3Write the severity definitionsThree or four levels, each with what it obliges the team to do. Put them on a wiki page and link it from the project. 4. 4Add the fields you will want laterSeverity, affected service, customer impact, and detection method, as custom fields so you can report on them. 5. 5Decide who can be incident commanderA named list, agreed in advance. The rota itself lives in whatever on call tool you use. 6. 6Set the monthly action reviewOne recurring meeting to check open postmortem actions. Without it, the actions rot. Orangescrum does not do alerting or paging. Keep your monitoring and on call tooling. This is where the record, the coordination, and the follow up work live. The result ## What good _looks like_ One record, from the first minute Nobody duplicates investigation because everything routes to the same place. Somebody is clearly in charge The incident commander is named on the record, so decisions get made rather than discussed. Support can answer customers Tickets are linked to the incident, so one update covers all of them. The timeline exists The postmortem is built from what was written down at the time, not from memory a week later. Follow up actions are real work They have owners, due dates, and a monthly review, so they get done or get closed honestly. You can see the pattern Reporting on incidents by service and detection method tells you where to invest. Watch out ## Where this _usually goes wrong_ No incident commander Five capable engineers all investigate, nobody decides, and the fix takes twice as long. ✓ Name one person on the record within the first five minutes. The timeline is reconstructed afterwards The postmortem is built from three people's memories and misses the important detail. ✓ Comment on the record as you go. It takes seconds and it is the whole value. Responders write the customer updates The people fixing it are interrupted constantly and the fix slows down. ✓ A separate communications lead with update tasks on a fixed cadence. Mitigation is treated as the fix Service is restored, the incident is closed, and the root cause is still there. ✓ Close the incident on restoration and raise the real fix as its own defect. Postmortem actions disappear Eight actions are agreed and none is a task, so the same incident recurs. ✓ Every action becomes a task with an owner, a due date, and a link back to the incident. Blame in the postmortem People stop reporting incidents early, which makes everything worse. ✓ Write the postmortem about the system, and keep names out of the causes. Features used ## Everything this _runs on_ The Microsoft Teams integration is available in the Self-Hosted edition. The rest is in both Cloud and Self-Hosted. [Bug and issue trackingThe incident record and the root cause fix](/bug-and-issue-tracking)[TicketingCustomer tickets linked to the incident](/ticketing-software)[Custom status workflowInvestigating, mitigating, monitoring, resolved](/custom-status-workflow)[MentionsPull the right person in, on the record](/mention)[WikiSeverity definitions and postmortems](/wiki-management)[Advanced reportingOpen actions, by age and by service](/advanced-reporting)[Microsoft TeamsUpdates into a channel, in Self-Hosted](/integrations/microsoft-teams)[Custom fieldsSeverity and affected service as real data](/custom-fields) Frequently asked questions ## Incident management _FAQ_ Is Orangescrum an alerting or paging tool? No. It does not do monitoring, alerting, on call rotas, or paging, and it does not host a public status page. Keep the tools you have for those. Orangescrum holds the incident record, the coordination, and the follow up work. Why does the incident need a commander? Because without one, several capable people investigate in parallel and nobody makes decisions. The commander coordinates rather than debugs, and it is often better if they are not the most senior engineer present. How do we keep an incident timeline? Comment on the incident record as things happen, with mentions when you need somebody. It feels like overhead during the incident and it is the entire basis of the postmortem afterwards. Should the incident and the root cause fix be the same item? No. Close the incident when service is restored, and raise the proper fix as a separate defect so it goes through normal prioritisation rather than being rushed. How do we stop postmortem actions being forgotten? Make each one a task with an owner and a due date, linked back to the incident, then review the open ones monthly. An action with no owner is not an action. Can support see which tickets relate to an incident? Yes. Link the tickets to the incident, so one update covers all of them and support is not answering the same question thirty times. Which template should the incidents project use? Bug Tracking. It opens on a board, which is the right view for a live queue, and you can set the incident specific statuses on top of it. Can we get incident updates into a chat channel? The Microsoft Teams and Slack integrations are available in the Self-Hosted edition, as plugins. There is no Zoom or Zapier integration in any edition. ## Stop losing the follow up actions The incident record, the timeline, and the work that comes after it, in one place. [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_incident-management_cta)[Book a Demo](https://calendly.com/orangescrum) ## Related use cases [Bug triageWhere the root cause fix gets prioritised](/use-cases/bug-triage)[Product launchLaunch week has its own war room](/use-cases/product-launch)[Sprint planningWhere follow up actions get scheduled](/use-cases/sprint-planning)[Bug Tracking templateThe project template this starts from](/project-templates/bug-tracking) [See all use cases →](/use-cases)