Incident report template

The most common mistake: mixing the incident report with the post-mortem. The incident report is facts only, filed within 24 hours while memory is fresh. The post-mortem is the analysis of why — written later, once you have data. Conflating them lets speculation enter the factual record, which creates legal and compliance problems.

Draft it with your agent

Paste this into Claude, Cursor, or any agent — it drafts the incident report and publishes it as a Drafty link your team can comment on directly:

See it on a real one

What goes in an incident report

1. Incident summary — date, time, exact location, report ID, reporter name, and severity level. This block is what compliance teams and managers read first.
2. Factual description — what happened, in chronological order, past tense. Stick to what was directly observed. "The server returned 503 errors from 14:02 to 14:47 UTC" beats "the system had problems."
3. People involved — names, job titles, departments, and contact information for anyone directly involved or affected.
4. Witness statements — names and brief accounts from anyone who observed the event. Collect these within 24 hours; memory accuracy drops sharply after 72 hours.
5. Immediate actions taken — what was done in the moment: who was notified, what was shut down or escalated, medical response if applicable.
6. Evidence — photos, logs, timestamps, screenshots. List what exists and where it's stored.
7. Next steps — corrective actions with a named owner and a due date. This is the accountability section, not the analysis.

When to use this template

• Workplace injuries or near misses — required for OSHA recordkeeping when the threshold is met.
• Security incidents — unauthorized access, data exposure, policy violations.
• Service outages — for SaaS teams, a fast incident report precedes the post-mortem; stakeholders get the facts while the investigation runs.
• Property damage or environmental events — any physical incident that may have regulatory or insurance implications.

If you need to go deeper on root cause, that's a separate post-mortem or RCA document. An incident report filed clean and fast gives the post-mortem a reliable foundation to build on.

The sharing problem most incident reports have

You draft it in a Google Doc. You email it to HR, legal, and the team lead. One person replies with corrections. Another sends a "comments" version as an attachment. You end up with four files and no single authoritative record — which is exactly the problem compliance processes exist to prevent.

Share a Drafty link instead. Sign-off comments anchor to the exact sentence — "the timeline in section 2 is off by 15 minutes" lands on that line, not floating in an email thread. Your agent can ship the correction at the same URL, with version history intact, so there's always one source of truth.

FAQ

What should an incident report include?

At minimum: date, time, and location; a factual description of what happened; the names and roles of everyone involved; witness statements; immediate actions taken; and next steps with owners. For workplace injuries, OSHA has specific recordkeeping fields — your template should map to those if compliance is required.

How soon after an incident should the report be filed?

Within 24 hours, ideally. Witness memory degrades fast — accuracy drops significantly after 72 hours. Filing quickly also satisfies most regulatory and internal policy windows. If the full details aren't available yet, file what you have and add an addendum rather than waiting.

What's the difference between an incident report and a post-mortem?

An incident report is a factual record filed close to the event — what happened, who was involved, what was done. A post-mortem (or RCA) is the analytical retrospective — why it happened and how to prevent recurrence. Keep them as separate documents. Mixing them lets unverified analysis contaminate the factual record.

Who fills out an incident report?

Typically the person who witnessed or was involved in the incident, or their direct supervisor. For technical incidents (outages, security events), the on-call engineer or incident commander usually owns the first draft. Someone with sign-off authority — an HR lead, safety officer, or engineering manager — should review before the report is finalized.

How do I write an incident report without assigning blame?

Describe actions and observations, not intentions or character. "The valve was left open" not "John forgot to close the valve." Passive constructions are useful here when the focus should be on the event rather than the individual. Save accountability questions for the post-mortem, where you have the full picture.