DETECT → RECORD → REVIEW
An IT incident report is the record of what happened while the pressure was on: what broke, the timeline, the measured impact, and what was done about it. This template keeps it to seven sections so the next on-call engineer can reconstruct the incident in minutes. Copy the plain-text version below, or capture the same investigation in SolveStack and export it as Markdown or ZIP.
THE TEMPLATE
The worked example below is illustrative — not a real incident. It shows how each section reads when filled in.
The facts that file the report: a unique incident ID, the date and time window with timezone, who commanded the response, and which systems were affected. Someone reading this a year later should be able to find every related artifact from this block alone.
ILLUSTRATIVE EXAMPLEINC-2026-118. Search API elevated p99 latency, detected 09:15 UTC. Commander: Riley. Systems: search-api (us-east), query cache tier. Not a real incident.One level, assigned once, not debated in the report. S1 means customers cannot use the service; S2 means major degradation with a workaround; S3 means limited impact; S4 means no customer impact. The severity field carries the weight, so the prose does not have to.
ILLUSTRATIVE EXAMPLES2 — major degradation with a workaround. Search results were slow but available; cached results served most traffic. Not a real incident.A timestamped sequence from first symptom to confirmed resolution. Record what was observed and what was done at each step — including the dead ends. The timeline is the evidence the rest of the report stands on. A report without one is a press release.
ILLUSTRATIVE EXAMPLE09:15 — p99 latency alert fires on /search. 09:22 — on-call confirms cache hit rate dropped to 31%. 09:40 — cache node restart attempted, no effect. 10:05 — faulty config push identified and rolled back. 10:40 — latency back to baseline, incident closed. Not a real incident.What the incident cost, in measurements you actually have: error counts, durations, affected users or systems. If the numbers are estimates, say so and note the source. Impact written from the dashboard survives; impact written from memory does not.
ILLUSTRATIVE EXAMPLEp99 latency above 2s for 85 minutes; ~12% of search queries affected; no failed checkouts (search is read-only). Counts from the search-api dashboard. Not a real incident.What the investigation concluded, stated as a cause you can change — or marked as still under investigation with a date. If the analysis deserves its own document, point to it: the incident report is the record, the root cause analysis is the deep work. For the deeper analysis, use the RCA template.
ILLUSTRATIVE EXAMPLEA cache-configuration push at 08:58 UTC changed the eviction policy without a canary step; hot keys were evicted and the origin absorbed the load. Full chain documented separately. Not a real incident.What was done to stop the current impact — the rollback, the restart, the failover — in the order it happened. Remediation is what made the incident end, distinct from the actions that stop the next one.
ILLUSTRATIVE EXAMPLE10:05 — configuration rolled back to the previous version. 10:12 — cache tier warmed from the last snapshot. 10:40 — latency at baseline for three consecutive checks; incident closed. Not a real incident.Every action gets an owner and a date. An action without both is a wish. Separate the immediate follow-ups (verify the fix held) from systemic fixes (stop the recurrence). If an action cannot be scheduled, say so explicitly rather than letting it drift.
ILLUSTRATIVE EXAMPLEImmediate: verify cache hit rate holds above 90% for 48 hours (Riley, this week). Systemic: require canary deploys for cache-config changes (Sam, next sprint). Systemic: add a cache-hit-rate page threshold (Riley, next sprint). Not a real incident.COPY-PASTE VERSION — PLAIN TEXT
INCIDENT REPORT =============== Incident ID: Date (start–end, with timezone): Severity (S1–S4): Incident commander: Systems affected: 1. INCIDENT IDENTIFICATION Unique ID, detection time, commander, affected systems. 2. SEVERITY S1 = customers cannot use the service. S2 = major degradation, workaround exists. S3 = limited impact. S4 = no customer impact. 3. INCIDENT TIMELINE HH:MM TZ — what was observed or done HH:MM TZ — HH:MM TZ — resolution confirmed 4. IMPACT Measured cost: counts, durations, affected users or systems. Mark estimates as estimates, with the source. 5. ROOT CAUSE The confirmed cause (a cause you can change), or "under investigation" with a date. For the deep analysis, see the RCA template. 6. REMEDIATION What stopped the current impact, in order: - HH:MM TZ — action taken 7. ACTION ITEMS - [ ] Immediate: action — owner — due date - [ ] Systemic: action — owner — due date
RUN IT LOCALLY
An incident report is only as good as the notes taken during the incident. SolveStack gives an IT investigation a durable 7-part structure while the work is still happening — then exports the whole record as portable files.
QUESTIONS
Incident ID, severity, a timestamped timeline, measured impact, the root cause, remediation steps, and action items with owners and dates. This template covers all seven, plus a worked example. Keep each section short — the report is a record for the next on-call engineer, not a narrative.
An incident report records what happened: timeline, impact, and what was done. A postmortem, or root cause analysis, goes deeper into why it happened and how to prevent a repeat. Write the report during the incident; do the analysis after. For the deeper analysis, the RCA template covers the problem statement, timeline, 5 whys, and corrective actions.
Timestamp every observed symptom and every action taken, including the dead ends. A timeline with five precise entries beats twenty vague ones — it is the evidence the rest of the report stands on. If you cannot reconstruct it after the fact, the report was started too late.
Use measurements you actually have: error counts, durations, affected users or systems. Avoid adjectives like severe or major — the severity field already carries that. If the numbers are estimates, say so and note the source.
No. The example on this page is illustrative — not a real incident from SolveStack or any customer. It shows how each section reads when filled in, with realistic-looking but invented details.
Yes. Capture the symptom, observations, evidence, and hypotheses in SolveStack while the incident is happening — data stays in your browser's IndexedDB, no account needed — then export the record as Markdown, HTML, JSON, or ZIP.