An incident management workflow is the sequence a team uses to detect a service disruption, organize its response, restore service, and learn from the event. Each stage needs an owner, a recorded next action, and a condition for moving forward. A ticket that changes status without those details does not tell responders what to do.
For a customer-facing service, a practical flow is detect and log → assess impact → declare and assign → investigate and mitigate → verify recovery → close and review → track improvements. Investigation and communication run alongside the response. The workflow below is a starting point to adapt to your services, coverage, and existing policies.
Incident management workflow: stages and decision points
| Stage | Main owner | Record | Decision to move forward |
|---|---|---|---|
| Detect and log | First responder | Symptoms, affected service, first known impact, and alert or report | Is the report actionable, a duplicate, or an unrelated request? |
| Assess impact | Responder or service owner | Affected users, functions, locations, and workarounds | Does it meet incident criteria? Which response priority applies? |
| Declare and assign | Incident coordinator | Incident record, responders, roles, and communication channel | Have the required owners accepted the work? |
| Investigate and mitigate | Technical lead | Hypotheses, evidence, proposed changes, and results | Has customer impact stopped or reduced? Is another action needed? |
| Verify recovery | Technical lead with support | Monitoring, representative user checks, and remaining limitations | Do the agreed recovery criteria hold? |
| Close and review | Incident coordinator | Final status, timeline, contributing causes, and lessons | Are follow-up tasks owned and the outcome communicated? |
| Track improvements | Named action owners | Due dates, evidence of completion, and runbook changes | Have the agreed improvements been verified? |
Use this as a process map rather than a rigid approval queue. A high-impact event may require declaring the incident and notifying the response team while the first responder continues gathering facts.
1. Detect the incident and create one shared record
Detection can come from monitoring, an employee, or a customer. Capture what is observed before assuming a cause: “Checkout requests return an error” is a symptom; “The database is down” is a hypothesis unless evidence confirms it.
Start a record with a unique reference, service name, first report time, time zone, current symptoms, and links to alerts or tickets. Distinguish the time someone noticed the issue from the earliest confirmed impact. If the onset is unknown, record that uncertainty.
When several support tickets describe the same failure, link them to the shared incident and retain each customer’s context. Support should be able to find the latest approved status without asking the technical team to repeat it for every ticket. Our support ticket escalation process explains the handoff into the responsible team.
2. Assess impact and set response priority
Ask which service functions fail, who is affected, when the problem began, whether the impact is growing, and whether a workable alternative exists. Prioritize the effect on users and the business rather than the number of notifications.
| Observed condition | Response consideration | Information to confirm |
|---|---|---|
| A core function is unavailable to many customers | Coordinated incident response and service-owner involvement | Scope, affected regions or accounts, and alternative paths |
| A function is degraded for a limited group | Targeted response with continued impact monitoring | Failure rate, affected configuration, and whether scope is expanding |
| An isolated report has an effective workaround | Service-owner investigation or normal ticket handling, depending on policy | Whether the report points to a broader hidden failure |
| Possible unauthorized access or data exposure | Activate the designated security response path | Observed facts and approved evidence; specialist assessment follows |
Labels such as SEV1, P1, or “major” vary between organizations. Publish your definitions, who can declare or change severity, and which notification and coverage rules follow. A suspicion involving security should reach the designated team promptly rather than wait for ordinary troubleshooting.
3. Declare the incident and assign response roles
The Google SRE incident management guide separates coordination, technical operations, and communication. This helps a technical responder focus on mitigation while another person manages the overall response and updates.
| Role | Responsibility | Useful output |
|---|---|---|
| Incident coordinator or commander | Coordinates priorities, owners, resources, and decisions | Current response plan and next decision |
| Technical lead | Organizes investigation and service recovery work | Evidence, proposed action, verification, and remaining risks |
| Communication owner | Maintains consistent updates for support and stakeholders | Approved status and next update time |
| Timeline recorder | Records material events, actions, and handoffs | Timestamped incident history |
A small team may combine roles, but the responsibilities still need named owners. If one person is investigating, coordinating, and answering every customer, arrange help or simplify the communication path. Confirm a backup for unavailable responders and a deliberate handoff for shift changes.
Keep one main response channel and one shared incident record. When separate teams investigate different components, each work stream should report findings back to the coordinator. Record which person is making each change so responders do not apply conflicting actions.
4. Investigate and mitigate customer impact
Start from evidence: recent changes, error patterns, affected versus unaffected users, dependency health, and the available diagnostics. Write down the hypothesis behind an action and the result you expect. Change direction when evidence contradicts it.
Google SRE’s incident guidance prioritizes restoring service while preserving evidence for later analysis. A rollback or workaround can restore the user experience before the underlying cause is fully understood. Track the cause investigation separately if it continues after recovery.
For every proposed mitigation, record:
- The intended effect and the service or users it changes.
- The owner and approval required under the existing response policy.
- The evidence that would show success or failure.
- The rollback or alternative action if it worsens the situation.
- The outcome, including any remaining degraded functions.
Use prepared runbooks where they apply, and record deviations. “Restart everything” without a hypothesis can hide evidence and introduce another failure. If a third-party service is involved, open the required vendor case, link it to the incident, and keep responsibility for your own customer updates.
5. Communicate throughout the incident
A customer update needs the affected function, current impact, available workaround, and next update time. The internal record can contain technical detail; public messages should reflect confirmed facts and approved information. Do not publish a suspected cause as settled or promise a fix time the responders have not confirmed.
Incident: [reference and short title] Updated: [date, time, time zone] Affected service / function: Known customer impact: Current status: [investigating / mitigation underway / recovery being verified] Workaround, if available: What happens next: Next update by: [date, time, time zone] Support or status-page contact:
Send the next update at the stated time even if the investigation is still open. Support can use the same approved facts across related tickets while explaining account-specific impact. A status page provides a shared reference when many customers are affected.
For visual symptoms, a Screendesk recording can supplement the initial report or show the recovered workflow. Include text, timestamps, and environment details, and keep diagnostic material in approved channels. A recording is one piece of evidence; it does not establish the cause on its own.
6. Verify recovery before declaring resolution
Agree on recovery criteria while responding. Check the customer-facing function, not just whether a server is running. Depending on the incident, that can mean a representative transaction succeeds, error rates return to the expected range, queued work catches up, and previously affected configurations work again.
- Verify the affected user journey using an approved check.
- Compare monitoring across the affected services, regions, or account groups.
- Check for delayed side effects such as backlogs or repeated failures.
- Record any functions still unavailable or operating under a workaround.
- Set an observation period appropriate to the failure and record who watches it.
If the checks fail, return to investigation and update the status. Once recovery is verified, communicate what is restored and what remains open. Resolution of the incident does not mean all prevention work is complete.
Worked example: checkout failures after a release
This fictional example shows the workflow; the times are illustrative and are not a promised service target.
| Time | Observed event or action | Workflow decision |
|---|---|---|
| 09:02 | Monitoring reports checkout errors; support receives matching reports | Create one incident record and link the tickets |
| 09:05 | Responder confirms failures across several accounts | Declare the incident, assign owners, and publish the first update |
| 09:10 | Technical lead finds errors began after a release | Record the release as a hypothesis and evaluate a rollback |
| 09:18 | Approved rollback completes; error rate declines | Move to verification rather than declare immediate resolution |
| 09:28 | Representative checkouts succeed and backlog processing is healthy | Continue the agreed recovery observation |
| 09:45 | Recovery checks remain healthy | Communicate restoration and assign follow-up investigation |
The rollback supports the conclusion that the release was involved. It does not, by itself, establish the exact defect. The follow-up investigation needs to explain the failure and verify the permanent correction before another release.
7. Review the incident and track improvements
Atlassian’s postmortem guidance connects the incident timeline, impact, response, and corrective work. Use the review to understand contributing conditions and improve the system. Give every agreed action an owner and a deadline so it reaches the backlog rather than remaining an observation.
Incident reference and summary: Customer impact and affected period: Timeline with confirmed timestamps: Detection and declaration: Mitigation and recovery evidence: Contributing causes: [confirmed / still under investigation] What helped the response: What delayed detection, decisions, or updates: Follow-up action | owner | due date | completion evidence: Runbook and communication changes: Related support tickets and engineering work:
A useful action is specific and verifiable: “Add an approved checkout smoke check to the release process, owned by [team], due [date].” “Be more careful” does not change the system. Link confirmed defects to a Jira bug report with evidence and expected behavior.
What to automate and what to measure
Automation can create an incident record, attach alert context, notify the current responder, and link related records. Keep duplicates, delivery failures, and out-of-hours coverage in the design. High-impact recovery actions need the authorization and verification your response policy requires. Do not assume automating a notification makes someone accept the incident.
Measure distinct stages instead of relying on an ambiguous “MTTR” label. Record impact start, detection, acceptance, mitigation, verified recovery, and closure. State whether your recovery measure starts at impact or detection and whether it ends at mitigation or verified restoration. Separate incidents by service and severity before comparing them.
Review delayed acknowledgements, missed update times, repeated incident patterns, and overdue follow-up actions alongside durations. A shorter average can hide one prolonged high-impact incident. Use the timeline to identify the specific delay and check whether the next process change addresses it.
Frequently asked questions
What is the difference between incident and problem management?
Incident work focuses on restoring service and coordinating the disruption. Problem-management work investigates contributing causes and prevention. A service may be restored with a workaround while the underlying problem remains open.
Is an incident management workflow the same as a ticket workflow?
A ticket can track an incident, but the response also needs roles, communication, recovery decisions, and evidence. Ticket status labels should reflect those activities rather than replace them.
Does every incident need a separate commander and scribe?
No. Combine responsibilities when the workload allows it, but identify who owns each one. Add responders or separate roles when coordination or communication starts interrupting recovery work.
How do you know the incident is over?
The responsible owner confirms the agreed recovery checks and communicates the final service status. Open follow-up tasks can remain after the incident closes, with their own owners and verification.
