Incident Timeline Template

Overview

Most incident postmortems fail to identify the real problems because they lack an accurate timeline. Teams remember the big events but forget the 15-minute delay in escalation, the 30 minutes spent looking at the wrong logs, or the gap between the first alert and human acknowledgment. This template structures incident reconstruction around five-minute granularity, exposing the delays that actually drive MTTR.

A timeline does two jobs at once: it’s the evidence base for the postmortem review and the input for your MTTR trend analysis. Without it, “we should respond faster” stays a feeling instead of a measured gap.

When to Use

Use this template when:

• Conducting a postmortem after any P1 or P2 incident
• An incident took considerably longer to resolve than expected
• You need to identify whether alerting, tooling, or process gaps contributed to delays
• Building a case for infrastructure or monitoring improvements

For coordinating stakeholder updates during the incident itself, use the incident communication template; this one is for reconstruction after the fact, not live comms.

Prerequisites

Before reconstructing the timeline:

• Gather logs from all affected systems (application, infrastructure, network)
• Collect alert timestamps from your monitoring system
• Review Slack/Teams incident channel history
• Interview each responder who participated in the incident
• Pull deployment logs and configuration changes for the preceding 24 hours

Solution

# Incident Timeline: `<Incident Title>`

## Metadata

| Field | Value |
|-------|-------|
| Incident ID | ______ |
| Severity | P1 / P2 / P3 / P4 |
| Date | ______ |
| Service(s) Affected | ______ |
| Incident Commander | ______ |
| Timeline Author | ______ |

---

## Summary

| Metric | Value |
|--------|-------|
| Time to Detect (TTD) | ______ |
| Time to Acknowledge (TTA) | ______ |
| Time to Mitigate (TTM) | ______ |
| Time to Resolve (TTR) | ______ |
| Total Customer Impact Duration | ______ |

---

## Detailed Timeline

| Time (UTC) | Event | Source | Actor | Notes |
|------------|-------|--------|-------|-------|
| T-2:00:00 | Last known healthy state | Monitoring dashboard | System | Baseline metrics normal |
| T-1:30:00 | Configuration change deployed | CI/CD logs | deploy-bot | [link to change] |
| T-0:45:00 | Latency begins increasing | APM metrics | System | p95 rises from 200ms to 500ms |
| T-0:15:00 | First error rate spike | Error tracking | System | 0.1% → 2% error rate |
| T+0:00:00 | **Alert fires: High error rate** | PagerDuty | System | Threshold: >1% for 5 min |
| T+0:05:00 | On-call engineer paged | PagerDuty | System | |
| T+0:12:00 | On-call engineer acknowledges | PagerDuty | [Engineer Name] | Delay: 7 min (investigating other alert) |
| T+0:15:00 | Incident declared in Slack | Slack | [Engineer Name] | Channel: #incident-xxx |
| T+0:18:00 | Initial log investigation begins | Shell | [Engineer Name] | Checked application logs first |
| T+0:25:00 | Identified correlation with deployment | Git history | [Engineer Name] | Found config change at T-1:30:00 |
| T+0:30:00 | Attempted rollback | CI/CD | [Engineer Name] | Rollback failed: new migration blocking |
| T+0:35:00 | Escalated to platform team | Slack | [Engineer Name] | Platform engineer joins at T+0:40 |
| T+0:45:00 | Platform team identifies DB connection pool exhaustion | DB metrics | [Platform Eng] | Connection pool maxed at 100 |
| T+0:50:00 | Applied emergency connection pool increase | Config change | [Platform Eng] | Temporarily raised to 200 |
| T+0:55:00 | Error rate begins dropping | Monitoring | System | Down to 0.5% |
| T+1:00:00 | Service declared mitigated | Incident channel | [Engineer Name] | Customer impact reduced |
| T+1:30:00 | Root cause confirmed: config change leaked connections | Code review | [Platform Eng] | Connection not closed in new path |
| T+2:00:00 | Permanent fix deployed | CI/CD | [Engineer Name] | Proper connection cleanup added |
| T+2:15:00 | Monitoring confirms stability | Dashboards | System | Metrics at baseline for 15 min |
| T+2:15:00 | **Incident resolved** | Incident channel | [Engineer Name] | |

---

## Delay Analysis

| Gap | Duration | Root Cause | Action Item |
|-----|----------|------------|-------------|
| Alert to Acknowledge | 7 min | Engineer investigating lower-priority alert | IMPROVE-1: Separate alert routing for P1 vs P2 |
| Acknowledge to Incident Declaration | 3 min | Engineer attempted solo troubleshooting first | IMPROVE-2: Require incident declaration within 5 min of P1 alert |
| Rollback Failure | 5 min | Migration conflict not documented in runbook | IMPROVE-3: Update rollback runbook with migration handling |
| Escalation Delay | 10 min | Platform team not auto-included for DB issues | IMPROVE-4: Add DB alerts to platform team routing |
| Detection Gap | 15 min | Latency increase did not trigger alert | IMPROVE-5: Add latency alert at p95 >400ms |

---

## What Went Well

1. [Positive observation about response]
2. [Positive observation about communication]
3. [Positive observation about tooling]

## What Went Poorly

1. [Negative observation about detection/alerting]
2. [Negative observation about response process]
3. [Negative observation about documentation/runbooks]

## Action Items

| ID | Action | Owner | Due Date | Priority |
|----|--------|-------|----------|----------|
| IMPROVE-1 | ______ | ______ | ______ | High |
| IMPROVE-2 | ______ | ______ | ______ | High |
| IMPROVE-3 | ______ | ______ | ______ | Medium |
| IMPROVE-4 | ______ | ______ | ______ | Medium |
| IMPROVE-5 | ______ | ______ | ______ | High |

How It Works

The timeline exposes gaps: the periods where nothing useful happened. Most MTTR improvement comes from eliminating these gaps, not from making active work faster. The template forces you to document the source of each timestamp (log line, Slack message, monitoring system) so the timeline is verifiable, not based on memory. The delay analysis converts the timeline into useful improvements rather than just a historical record.

The T± notation anchors everything to the moment the first alert fired. Events before T+0 form the detection gap; events after it map to response phases:

Each arrow is a measurable segment. Add up the arrows and you get MTTR; shorten the longest arrow and MTTR drops. That’s why the delay analysis table exists: it turns “the incident took two hours” into “detection gap was 15 minutes and escalation ate 10.”

Running the Reconstruction Session

Don’t build the timeline alone in a doc. Run a 45-minute session within 48 hours of resolution, while details are still fresh. Memory decay is brutal here: responders reliably reconstruct the sequence of events for a day or two, but by day five they start filling gaps with what “should” have happened — and a reconstructed-from-plausibility timeline produces plausible action items instead of real ones.

The session format that works:

1. Scribe drafts the skeleton from machine sources only: alerts, deploys, monitoring events. No interviews yet.
2. Responders fill gaps live. Share the draft in the meeting. People remember “oh, that’s when I noticed X” when they see a timestamped anchor.
3. Challenge every gap over 10 minutes. “What were we doing here?” usually surfaces a missing alert, a slow escalation, or someone stuck on a wrong hypothesis.
4. Assign every delay to a system cause, not a person. “7 minutes to acknowledge” becomes “alert arrived while engineer was handling another incident,” which maps to a routing fix, not a performance conversation.

The session output feeds directly into your postmortem review and your escalation policy updates.

Timestamp Sources Ranked by Reliability

Source	Precision	Watch out for
Monitoring metrics (Datadog, Prometheus)	Seconds	Retention windows may drop early events
Alert systems (PagerDuty, Opsgenie)	Seconds	Alert ≠ detection; the metric may have breached earlier
CI/CD logs	Seconds	Deployment time ≠ propagation time
Chat history (Slack, Teams)	Seconds	”Working on it” ≠ actual action start
Responder interviews	Minutes	Memory compresses delays; use as a supplement, not a source
Support tickets	Minutes	Customer-reported start is the true impact start

When sources disagree, prefer machine timestamps and note the discrepancy. A responder remembering “I acknowledged immediately” while PagerDuty shows 7 minutes isn’t a lie; it’s exactly the perception gap the timeline exists to catch.

Real Incident Timeline Example

=== Incident Timeline: INC-2026-07-11-001 ===

Severity: SEV1 (Critical)
Service: auth-service
Start: 2026-07-11 10:55 UTC
End:   2026-07-11 11:25 UTC
Duration: 30 minutes

TIMELINE:
10:42  [SYSTEM]  DB CPU usage begins rising (CloudWatch metric)
10:50  [SYSTEM]  DB CPU hits 95% (threshold: 80%)
10:52  [SYSTEM]  Login latency p99 exceeds 2s (threshold: 1s)
10:55  [ALERT]   PagerDuty alert fires: "auth-service latency critical"
10:55  [ALERT]   PagerDuty alert fires: "DB CPU critical"
10:57  [HUMAN]   On-call engineer acknowledges both alerts
10:58  [HUMAN]   On-call opens incident channel #inc-2026-07-11
11:00  [HUMAN]   On-call declares SEV1 — 15% of logins failing
11:01  [HUMAN]   On-call checks recent deployments — config deploy at 10:40
11:03  [HUMAN]   On-call identifies config change: JWT secret rotation interval
11:04  [HUMAN]   On-call notifies #support channel of login issues
11:05  [HUMAN]   On-call initiates rollback of config change
11:08  [SYSTEM]  Config rollback deployed
11:08  [HUMAN]   On-call monitors error rate: 15% -> 8% -> 3%
11:12  [SYSTEM]  Error rate drops below 0.5%
11:12  [HUMAN]   On-call updates status page: "Issue identified, fix deployed"
11:15  [HUMAN]   On-call monitors for 10 minutes (stability window)
11:25  [HUMAN]   On-call declares incident resolved
11:25  [HUMAN]   On-call updates status page: "Resolved"

DELAY ANALYSIS:
  Detection -> Alert:        3 min  (DB CPU rising at 10:42, alert at 10:55)
  Alert -> Acknowledge:      2 min  (Good)
  Acknowledge -> Declare:    3 min  (Good)
  Declare -> Identify:       4 min  (Good — checked recent deploys)
  Identify -> Fix:           3 min  (Good — fast rollback)
  Fix -> Stable:             7 min  (Acceptable — error rate drain)
  Stable -> Resolve:        10 min  (Standard stability window)

TOTAL: 30 minutes (Target RTO: 30 min — MET)

This incident went well — every segment under target except the stability window, which is deliberate. Notice what’s still worth capturing: the 13-minute detection gap before any alert fired (DB CPU rising at 10:42, first alert at 10:55) is the single largest improvement opportunity, even in a “good” incident.

Variants

The same skeleton adapts to different audiences and incident types. Adjust the granularity and vocabulary, not the discipline of sourcing every timestamp:

Context	Focus	Notes
Blameless postmortem	Process and system gaps	Avoid naming individuals; focus on system failures
Executive summary	Business impact timeline	Compress to 5-10 key events with customer impact
Security incident	Attack vector timeline	Include attacker actions and defensive responses
Performance degradation	Metric correlation	Focus on metric changes and their cascading effects

Best Practices

1. Build the timeline during the incident, not after: assign a scribe to capture timestamps in real time
2. Include “negative” events: note when expected alerts did NOT fire
3. Cross-reference multiple sources: don’t rely on a single log source; memory is unreliable
4. Quantify every gap: “we spent some time” is useless; “12 minutes” drives improvement
5. Review timelines monthly: look for patterns across incidents rather than treating each as unique

Common Mistakes

1. Building the timeline from memory: humans compress time and omit uncomfortable delays
2. Only including successful actions: the failed rollback that wasted 10 minutes is more valuable than the eventual fix
3. Using imprecise timestamps: “around 2:30” isn’t good enough; use exact UTC timestamps
4. Forgetting the detection gap: the time between when the problem started and when the alert fired is often the largest gap
5. Not connecting timeline to action items: a timeline without follow-up actions is just a story

Timeline Quality Checklist

Before publishing the timeline, verify it against this list:

• Every timestamp is in UTC with second or minute precision; no “around” or “roughly”
• Every event cites its source (log, alert, chat, interview); a timeline without sources can’t be verified
• The detection gap is documented: the delta between first metric deviation and first alert
• All gaps over 10 minutes have an annotation, even if it’s “investigating X, no progress”
• Failed actions appear alongside successful ones: rollbacks that didn’t work, dead-end hypotheses
• Expected-but-missing events are noted (e.g., “DB alert should have fired at T-0:45 but didn’t”)
• The delay analysis maps every gap to a system-level cause and a concrete action item
• At least one responder besides the scribe has reviewed the timeline for accuracy
• The delay analysis section lists concrete owners and due dates, not vague intentions

A timeline that passes this checklist feeds the postmortem; one that fails it becomes a narrative. Interesting to read, but it will not drive the systemic improvements that actually reduce MTTR over the next quarter.

Troubleshooting

• Sources show conflicting timestamps: normalize everything to UTC first. A Slack message in PDT and a CloudWatch event in UTC will look like a 7-hour gap until you convert. If the conflict persists, trust the machine timestamp and annotate the disagreement.
• Nobody remembers what happened during a gap: pull the incident channel’s emoji reactions and message edits; they’re timestamped and often reveal when hypotheses changed. Check git blame sessions or terminal history if the responder ran commands.
• The timeline contradicts the engineer’s account: that’s the point of the exercise. Present the machine data without accusation; the correction (“I thought I responded fast, but it took 9 minutes”) is the learning, not a fault.
• Logs expired before the postmortem: run reconstruction within 48 hours. If your log retention is shorter than your postmortem cadence, that’s the first action item.
• Timeline is complete but the postmortem still stalls: the timeline shows when, not why. Pair it with a postmortem review that walks the causal chain behind each gap.

Further Reading

• Google SRE Book — Postmortem Culture: the canonical argument for blameless reconstruction and why timelines anchor it.
• Atlassian — Incident Postmortem Guide: facilitation structure for the review meeting that consumes the timeline.
• The List of Public Postmortems: dozens of real incident timelines from Google, Cloudflare, AWS and others to calibrate your granularity.
• PagerDuty — Post-Incident Review Guide: data sources and tooling for automated timeline capture.