Customer incident lifecycle sequence
Communication flow from detection through acknowledgment, investigation, resolution, and closure.
The gap between an incident and a customer's trust in your fix is filled by communication. This template maps every exchange: the initial acknowledgment (we see it, we're working on it), investigation updates (here's what we know so far), the resolution notice (it's fixed, here's what we'll do to prevent it), and the postmortem (this is exactly what happened). Each message matters — silence during an outage erodes trust even if you're fixing it furiously.
The sequence makes visible the rhythm of communication: rapid fire (ack in 5 min, update every 15) during active incident, then a promised postmortem within 48 hours. Teams that skip updates or publish postmortems weeks later find customers have already voted with their feet.
When to use this template
- Support runbook — share this with your support team so they know when to message customers and what information the on-call team will provide at each stage.
- SLA documentation — annotate each message with your target SLA (ack in 5 min, update every 15 min, resolve in 1 hour). This forces you to think about whether your SLA is achievable.
- Customer-facing incident guide — publish this on your status page so customers know what to expect and when to expect communication from you.
How to adapt it
Customize the sequence and timing to your SLA and communication model:
- Add a customer escalation path if large customers can request direct communication from your incident commander instead of going through support.
- Insert internal stakeholder updates (notify billing, alert account managers) if your incident affects contracts or renewals.
- Add a root-cause post after resolution if you want to publish technical findings immediately rather than waiting for the full postmortem.
Visual edits regenerate clean Mermaid sequence diagrams, so you can experiment with communication timing without touching syntax.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
sequenceDiagram
participant C as Customer
participant Mon as Monitoring
participant OC as On-Call
participant IC as Incident Commander
participant C2 as Customer Support
C->>Mon: Issue detected (outage/degradation)
Mon->>OC: Alert fires
OC->>IC: Acknowledge and declare incident
IC->>C2: Brief support on status
C2->>C: Send initial acknowledgment (ETA unknown)
IC->>OC: Assign investigation tasks
OC->>OC: Investigate root cause
OC->>IC: "Likely database failover delay"
IC->>C2: Update with working theory
C2->>C: Send update #1 (investigating, ETA 30 min)
OC->>OC: Implement fix / force failover
OC->>IC: "Fix deployed, monitoring"
IC->>C2: Ready to declare resolution
C2->>C: Send resolution notice (service restored)
C->>Mon: Service healthy (confirmed)
Mon->>IC: Metrics nominal
IC->>C2: Schedule follow-up postmortem
C2->>C: Send postmortem scheduled (48h review)
C2->>C: Postmortem publish (what happened, how to prevent)
Frequently asked questions
- What is a customer incident lifecycle sequence?
- It's a sequence diagram showing the flow of communication between your on-call team, incident commander, and customers from the moment an outage is detected through investigation, resolution, and postmortem. Every edge shows what the customer hears and when: initial ack, investigation updates, resolution, and root-cause details.
- Why send investigation updates if the incident is still ongoing?
- Because silence kills trust. If a customer has no update for 30 minutes during an outage, they assume you're not working on it. Regular updates (every 15–30 min) show progress and manage expectations. Even 'still investigating, no fix yet' is better than radio silence.
- When should I send the postmortem?
- Within 24–48 hours of resolution. Too soon and you're still learning; too late and momentum is lost. The postmortem should answer: what broke, why did it break, how long it lasted, how many customers it affected, and what we're changing to prevent it next time. Share it internally first, then publish for customers who want technical detail.
- How do I adapt this for my SLA commitments?
- Add timing constraints: 'acknowledge within 5 min', 'update every 15 min', 'resolve within 1 hour for SEV-1'. Sequence diagrams can show these as annotations on each edge. If your SLA requires specific ack formats or customer escalation, add those branches. Visual edits regenerate clean Mermaid, so you can layer in your SLA timers without touching syntax.
Related templates
Incident severity classification
Assess impact and urgency to classify severity and route to the right on-call tier.
SLA response state machine
Track support ticket states from submission through response and resolution SLAs.
Bug triage workflow
Classify, prioritize, and assign incoming bug reports systematically.