Incident Timeline: What to Record, a Free Template and Examples (2026)
Quick answer: An incident timeline is a chronological record of everything that happened during an incident: when the problem started, when it was detected, who was paged and when they responded, every decision and action, when service was restored and when the incident was closed. Each entry has a timestamp, a description, the person or system involved and its source. A good timeline is written during the incident, not reconstructed afterwards, and it's the foundation of the postmortem and of metrics such as MTTD, MTTA and MTTR.
Two days after an outage, the postmortem meeting starts with a simple question: when did it actually begin? Nobody is sure. The first alert fired at 14:06, but a customer emailed at 13:58. Someone restarted a service "around half past", but the chat history shows two people discussing it at different times. Half the meeting is spent rebuilding what happened instead of learning from it.
An incident timeline prevents that. It's the single shared record of what happened, in order, with evidence, and it turns an incident from a memory into data.
This guide covers what an incident timeline is, the timestamps every timeline needs and the metrics they produce, what to record in each entry, how to build a timeline during and after an incident, a free template with a filled-in example, and how timelines work for security incidents.
What is an incident timeline?
An incident timeline is the time-ordered log of an incident, from the first sign of trouble to the moment it's closed. It records events (an alert fired, a deploy went out, an error rate peaked), actions (a rollback, a restart, a failover), decisions (raising the severity, choosing not to fail over) and communications (a status page update, a message to executives).
It's sometimes called an incident log, an incident chronology or, in postmortems, a sequence of events. The format matters less than two properties: every entry has a precise timestamp, and every entry can be traced to its source.
Why it matters
Use | What the timeline provides |
|---|---|
During the incident | Anyone joining late can catch up without interrupting the people fixing it; handoffs between shifts don't lose information |
The postmortem | A shared, factual starting point, so the meeting is spent on causes and lessons instead of reconstructing events. See post-mortem meetings |
Root cause analysis | The order of events shows what happened before what, which is the evidence every root cause analysis method needs |
Metrics | Detection, acknowledgment, mitigation and resolution times all come from timeline timestamps |
Customers and contracts | Accurate impact windows for status page history, SLA reports and service credits |
Compliance | For security incidents, a defensible record of when the organization knew what, and what it did |
The eight timestamps every incident timeline needs
Most timeline entries are free text. Eight of them are milestones that should be recorded for every incident, because the reliability metrics your team reports are calculated from them.
# | Milestone | Definition | Where it usually comes from |
|---|---|---|---|
T0 | Impact started | The first moment users were affected | Metrics and logs, reviewed afterwards; often earlier than the first alert |
T1 | Detected | The first signal that something was wrong: an alert, a synthetic check, a customer report | Monitoring, support tickets |
T2 | Paged | The first notification sent to a responder | On-call tool |
T3 | Acknowledged | A person confirmed they're working on it | On-call tool |
T4 | Declared | The incident was formally opened, with a severity | Incident tool or channel |
T5 | Mitigated | User impact stopped, for example after a rollback or failover | Monitoring, the responders' notes |
T6 | Resolved | The service is fully restored and stable | Incident tool |
T7 | Closed | Follow-up done: postmortem held, action items logged | Incident tool, postmortem doc |
The metrics they produce:
Metric | Calculated as | What it tells you |
|---|---|---|
Time to detect (MTTD when averaged) | T1 − T0 | How long problems go unnoticed |
Time to acknowledge (MTTA) | T3 − T2 | How fast paging reaches a person |
Time to declare | T4 − T0 | How long before the response is organized |
Time to mitigate | T5 − T0 | How long users were affected; usually the number customers care about |
Time to resolve (MTTR) | T6 − T0 | The full length of the incident |
Two details make these numbers trustworthy. First, record T0 separately from T1. If the timeline starts at the first alert, every detection delay disappears from your metrics. Second, write down which definition you use for each metric; some teams measure MTTR from detection rather than from impact start, and mixing the two makes quarterly comparisons meaningless. All four core metrics are explained in our MTTR, MTTA, MTBF and MTTD guide.
What to record in each timeline entry
Every entry should answer five questions:
Field | What it holds | Example |
|---|---|---|
Time | Exact timestamp, in one time zone for the whole timeline, usually UTC | 14:06:12 UTC |
Type | Event, action, decision or communication | Action |
What happened | One factual sentence | Rolled back checkout-api from v2.41 to v2.40 |
Who | The person or system responsible | Priya (operations lead) |
Source | Where the evidence is: a graph, an alert, a chat message, a deploy record | Deploy log entry #8812 |
Decisions deserve one more thing: why. "Decided not to fail over to the secondary region" is a fact; "because replication lag was 40 minutes and failing over would lose orders" is what the postmortem actually needs.
Good and bad entries
Weak entry | Better entry | Why it's better |
|---|---|---|
"Things started breaking" | "14:02 UTC: checkout error rate rose from 0.1% to 6% (dashboard link)" | Exact time, a measurable symptom and evidence |
"Bob fixed the DB" | "14:19 UTC: Bob increased the connection pool from 200 to 300 on orders-db; error rate began falling at 14:21" | Says what changed, on which system, and the effect |
"Decided not to roll back" | "14:11 UTC: IC decided not to roll back because v2.41 contained a database migration; chose to scale the pool instead" | Records the reason, which is what a later reviewer will question |
"Customers were told" | "14:15 UTC: first status page update posted: login slow for some users; next update 14:45" | Shows what was said and when the next commitment was |
Write entries as facts, not judgments. "Alice missed the alert" assigns blame; "the alert went to the secondary, who was not on shift" describes the system. That difference keeps the postmortem blameless and makes the real cause easier to see.
How to build an incident timeline
The best timelines are written live and checked afterwards. Reconstructing everything from memory two days later is the slowest and least accurate way to do it.
During the incident
Name a scribe. On anything bigger than a minor incident, one person owns the timeline so that the people fixing the problem don't have to. On small incidents, the incident commander can do it. See incident response roles.
Use one place. The incident channel or the incident tool's timeline, not private messages and personal notes.
Log as you go. A short entry with a timestamp is enough in the moment; detail can be added later. "14:11 decided no rollback, migration in v2.41" is better than nothing.
Capture decisions and their reasons. Automated tools record alerts and pages; only people can record why a choice was made.
Mark the milestones explicitly as they happen: declared, mitigated, resolved.
After the incident
Merge the automatic sources. Pull in alert and page times from the on-call tool, deploys from the CI/CD system, config changes from version control and graphs from monitoring.
Find the real start. Look at metrics and logs before the first alert to set T0, the moment users were first affected.
Normalize time zones. Convert everything to one zone, usually UTC, and check that the clocks of different tools agree.
Fill the gaps. Where the record jumps, ask the people involved what happened and mark the entry as reconstructed.
Review it with the responders before the postmortem, so the meeting starts from an agreed set of facts.
Sources to pull from
Source | What it contributes |
|---|---|
Monitoring and observability | When metrics changed: the real T0, the peak and the recovery |
Alerting and on-call tool | When alerts fired, who was paged, when they acknowledged, escalations |
Incident channel (Slack, Teams) | Decisions, discussion, who joined when |
Deployment and version control | What changed, when and by whom |
Status page and support tool | What customers were told and what they reported |
Cloud provider and vendor status pages | Whether an upstream outage was involved |
Incident timeline template
Copy this into your incident doc, wiki or spreadsheet. Fill in the header when the incident is declared, and add rows as you go.
Header
Field | Value |
|---|---|
Incident ID and title | |
Severity | |
Incident commander | |
Scribe | |
Time zone for all entries | UTC |
Affected services |
Timeline
Time (UTC) | Milestone | Type | What happened | Who | Source |
|---|---|---|---|---|---|
T0 Impact started | Event | ||||
T1 Detected | Event | ||||
T2 Paged | Event | ||||
T3 Acknowledged | Action | ||||
T4 Declared | Decision | ||||
T5 Mitigated | Event | ||||
T6 Resolved | Decision | ||||
T7 Closed | Action |
Metrics (calculated from the milestones): time to detect, time to acknowledge, time to declare, time to mitigate, time to resolve.
Example: a database connection pool incident
An illustrative SEV2 on an e-commerce checkout service.
Time (UTC) | Milestone | Type | What happened | Who | Source |
|---|---|---|---|---|---|
13:58 | T0 Impact started | Event | Checkout error rate begins rising (found afterwards in metrics) | — | Checkout dashboard |
14:04 | T1 Detected · T2 Paged | Event | Checkout error-rate alert fires; payments on-call paged | Alerting | Alert #4471 |
14:07 | T3 Acknowledged | Action | Priya acknowledges the page and opens the incident channel | Priya | On-call tool |
14:09 | T4 Declared | Decision | Declared SEV2: about 6% of checkouts failing; Marco is incident commander | Marco | Incident channel |
14:10 | Event | Deploy log shows checkout-api v2.41 released at 13:52 | Priya | Deploy #8812 | |
14:11 | Decision | No rollback: v2.41 includes a database migration. Investigate the database instead | Marco | Incident channel | |
14:15 | Communication | First status page update: "Some checkouts are failing. Next update 14:45" | Sam (comms) | Status page | |
14:17 | Event | orders-db connection pool at 200 of 200; long-running report query holding connections | Priya | Database dashboard | |
14:19 | Action | Report query stopped; pool increased to 300 | Priya | Change #2291 | |
14:24 | T5 Mitigated | Event | Error rate back to baseline | — | Checkout dashboard |
14:45 | Communication | Status page: "Fixed; monitoring" | Sam | Status page | |
14:50 | T6 Resolved | Decision | Stable for 25 minutes; incident resolved | Marco | Incident channel |
Day +3 | T7 Closed | Action | Postmortem held; two action items filed | Marco | Postmortem doc |
Metrics from this timeline: time to detect 6 minutes (14:04 − 13:58), time to acknowledge 3 minutes, time to declare 11 minutes, time to mitigate 26 minutes, time to resolve 52 minutes.
Notice what the timeline reveals that memory wouldn't: users were affected six minutes before anyone was alerted, and the decision not to roll back at 14:11 had a clear, recorded reason. Both become questions for the postmortem, and the first is an alerting gap with a measurable cost. For the follow-up, see postmortem action items; for the wider incident record, the incident response template.
Incident response timelines for security incidents
In security, "incident response timeline" can mean two different records, and a serious incident needs both.
1. The attack timeline (forensic timeline analysis)
This reconstructs what the attacker did: initial access, the accounts and systems they touched, lateral movement, data accessed or exfiltrated. Analysts build it from logs, endpoint artifacts and file system metadata, often as a "super timeline" that merges many sources. Open-source tools such as Plaso and Timesketch are widely used for this, and mapping each step to MITRE ATT&CK techniques shows where detection failed.
A forensic timeline needs stricter handling than an operational one: preserve original evidence, record chain of custody and note how each timestamp was obtained, because the timeline may be used in legal or regulatory proceedings.
2. The response timeline
This records what the organization did and when it knew it: detection, escalation, containment decisions, notifications. For security incidents it has a legal dimension, because several regulations start a clock at the moment of awareness:
Regulation | Deadline |
|---|---|
GDPR (EU, personal data breaches) | Notify the supervisory authority within 72 hours of becoming aware, where feasible |
NIS2 (EU, essential and important entities) | Early warning within 24 hours, incident notification within 72 hours, final report within one month |
SEC cybersecurity disclosure (US public companies) | Disclose a material incident within four business days of determining it's material |
HIPAA (US health data) | Notify affected individuals without unreasonable delay, and no later than 60 days after discovery |
These deadlines are summaries, not legal advice; your legal team should confirm which apply. What they have in common is that the timeline must show clearly when the organization became aware, because that's when the clock starts.
Extra columns for a security timeline: add Actor (attacker activity or responder activity), Evidence reference (where the artifact is stored) and Notified (which internal or external parties were informed at that point).
Common incident timeline mistakes
Starting at the first alert. The incident began when users were affected, not when monitoring noticed. Starting at T1 hides every detection gap.
Mixed time zones. Chat in local time, logs in UTC and a status page in the provider's time zone produce entries that appear out of order. Pick one zone and convert everything.
No reasons for decisions. A timeline of actions without the reasoning behind them can't be reviewed fairly, and the postmortem ends up guessing.
Reconstructing from memory. Days later, people remember the order of events differently. Write entries live, even if they're short.
Blame in the wording. "Forgot to", "failed to" and "should have" turn a timeline into an accusation. Describe what happened and what the system allowed.
Only the technical events. Leaving out communications, such as status page updates and executive messages, makes it impossible to review whether customers were kept informed.
Never closing the incident. Without T7, nobody can see whether follow-up actually happened. Close the timeline when the postmortem and action items are done.
Where ITOC360 fits
ITOC360 Incident Response builds most of the timeline automatically, so the scribe can focus on decisions and reasons:
Milestones recorded as they happen. Alert received, page sent, acknowledgment, escalation, declaration and resolution are timestamped without anyone typing them.
One time zone. Every entry is stored in the same clock, whichever tool it came from.
Notes from chat. Responders can add timeline entries from Slack or Microsoft Teams without leaving the incident channel.
Metrics from the record. MTTA and MTTR are calculated from the same timestamps, so the numbers in your reports match the timeline your postmortem reviews.
The parts a tool can't capture, such as why a decision was made or when users were really first affected, still need a person. The timeline is where both meet.
Frequently asked questions
What is an incident timeline?
An incident timeline is a chronological record of an incident, from the moment users were first affected to the moment the incident was closed. Each entry has a timestamp, a description, the person or system involved and its source.
What should be included in an incident timeline?
The key milestones (impact start, detection, paging, acknowledgment, declaration, mitigation, resolution and closure), plus every significant event, action, decision and communication in between. Decisions should include the reason they were made.
How do you build an incident timeline?
Name a scribe, log entries in one place as the incident happens, and mark the milestones explicitly. Afterwards, merge timestamps from monitoring, the on-call tool, deploy logs and chat, find the real start of impact, convert everything to one time zone and review the result with the responders before the postmortem.
Who is responsible for the incident timeline?
Usually the scribe, a role assigned during the incident. On smaller incidents the incident commander keeps it. The incident commander is accountable for its completeness.
What is the difference between an incident timeline and a postmortem?
The timeline records what happened and when. The postmortem uses the timeline to explain why it happened, what the impact was and what will change. The timeline is the evidence; the postmortem is the analysis.
What is an incident response timeline in cybersecurity?
It can mean the reconstructed timeline of an attack, built from logs and forensic artifacts, or the record of the organization's response. The response timeline matters for regulations such as GDPR and NIS2, whose notification deadlines start when the organization becomes aware of the incident.
What is forensic timeline analysis?
It's the process of building a single chronological view of system activity from many artifacts, such as logs, file system metadata and registry data, to reconstruct what an attacker did. Tools such as Plaso and Timesketch are commonly used to create and analyze these super timelines.
How do incident timelines relate to MTTR?
MTTR and related metrics are calculated from timeline milestones: time to detect is detection minus impact start, time to acknowledge is acknowledgment minus paging, and time to resolve is resolution minus impact start. An incomplete timeline produces misleading metrics.
Sources
Google SRE Book: Managing Incidents (the living incident document)