IT incident report template: one page, copy and fill in
An IT incident report is the record you keep after something broke: a server down, a mailbox migration gone wrong, a laptop fleet locked out. It is read later by your manager, an auditor, a client, or you six months on when the same thing happens. This page gives you a one-page template with a short note under each field saying what belongs there, and a filled-in example. The incident in the example is invented.
Who this is for
IT managers, sysadmins and managed-service shops that need a plain record of an incident, not a full engineering postmortem. If the reader is a customer who was affected, use the customer incident report guide, which puts impact and apology-free facts first. If the reader is your own team, a blameless review is the better fit; this record is the factual page that review starts from.
The template
INCIDENT REPORT: [short title, e.g. "File server unavailable"] Reference: [ticket or incident number] Severity: [your scale, with one-line meaning] Reported by: [role] Incident lead: [role] Report date: [date] 1. SUMMARY (2 sentences) What stopped working, for whom, from when to when. 2. IMPACT Systems and services affected: Users or sites affected (count, or "unknown"): Business effect (work stopped, data at risk, deadlines missed): Data lost or exposed? [yes / no / not yet known] + how you know. 3. TIMELINE (one zone, stated; use 24-hour times) [time] first sign (alert, user report, monitoring) [time] incident declared / ticket opened [time] actions taken, one line each [time] service restored [time] confirmed stable 4. CAUSE Confirmed cause: Contributing factors: Not yet known: 5. FIX AND WORKAROUNDS What restored service. Anything still temporary. 6. FOLLOW-UP ACTIONS Action | Owner (role) | Due date | Done? 7. SIGN-OFF Reviewed by: Date:
What belongs in each field
| Field | Put in | Leave out |
|---|---|---|
| Severity | The level from your own scale and what it means in a phrase ("S2: one site down, workaround exists"). | A level without a scale. "High" means different things to different people. |
| Summary | What, who, when. A reader who stops here still has the facts. | The cause, unless confirmed. Keep it for section 4. |
| Impact | A count or "unknown". State separately whether data was lost or exposed, and how you know. | "Minimal" or "some users" with no number and no basis. |
| Timeline | Times from logs or tickets, in one zone. Mark an estimate with "about". | Times from memory presented as exact. Mixed zones. |
| Cause | Only what you confirmed. Put guesses under "not yet known" or as "suspected". | A name. Write the role or the process gap. |
| Follow-up | One owner and one date each, so someone can ask "is it done?". | "Review procedures". Say which, and by when. |
Filled-in example (invented)
INCIDENT REPORT: File server unavailable at the Leeds office Reference: INC-0412 Severity: S2 (one site down, workaround exists) Reported by: Service desk Incident lead: IT manager Report date: 2026-03-12 1. SUMMARY The shared file server at the Leeds office was unavailable from 08:41 to 11:20 UTC on 2026-03-11. Staff there could not open shared files; the other two sites were not affected. 2. IMPACT Systems: file server LDS-FS1 and the mapped drives that use it. Users: about 35 at Leeds (count from the AD group; not all were in that day). Business effect: payroll preparation moved to the afternoon; no deadline missed. Data lost or exposed: no. The last backup at 02:00 was intact and the disk volume was not modified. 3. TIMELINE (UTC) 08:41 Service desk receives first call: drives not connecting. 08:50 Ticket INC-0412 opened; server found powered on but unreachable on the network. 09:15 Switch port for LDS-FS1 found in error state after an overnight firmware update. 10:05 Port reset; no change. Decision to move the server to a spare port. 11:20 Server reachable; drives reconnect. 11:45 Users confirm access; incident closed as stable. 4. CAUSE Confirmed: the switch port went into an error state after the firmware update. Contributing: the update was run on the switch overnight with no check of the server's link afterwards. Not yet known: why the port did not recover on its own; the vendor has been asked. 5. FIX AND WORKAROUNDS Server moved to a spare port. Still temporary: the original port is disabled until the vendor replies. 6. FOLLOW-UP ACTIONS Add a post-update link check to the switch change checklist | IT manager | 2026-03-20 | open Chase vendor on the port error | Network engineer | 2026-03-18 | open Test a restore from the 02:00 backup | Sysadmin | 2026-03-31 | open 7. SIGN-OFF Reviewed by: Operations director Date: 2026-03-13
Before you file it
- Every time has a zone and they all match.
- The impact section says whether data was lost, and how you know.
- Each cause is either confirmed or labelled suspected.
- Every follow-up has one owner and one date.
- No personal names, passwords or customer data. Use roles.
Working out durations and checking a customer version
Paste the timeline into the free timeline calculator and report checker to get time to detect, time to fix and total duration, and to see which parts of a customer-facing version are missing. It runs in your browser and uploads nothing. See also the annotated post-incident review example and the status page update templates.
If the reader is a client and you would like a first draft of the report, a status page post and a cover email made from your own notes, with every time or cause you did not give left as a marked blank, see the $9 draft service (AI-written by Claude, not legal advice).