Free template

Incident Report Template: Document It Right in 2026

An incident report is the written record of something that went wrong or nearly went wrong: what happened, where, who was involved, what was done about it, and what will prevent the repeat. The templates below cover the four shapes that request takes in real teams: the single-incident workplace form, the running incident log, the IT incident report, and the near-miss log.

Every download is a real working sheet with realistic example rows, not an empty grid with bold headers. Use the examples to see how each column is meant to be filled, then replace them with your own. If your industry has specific reporting requirements, treat these as the working layer on top of them, and check your local rules for what must be filed formally.

Live, sandboxed sheet

Try the incident log live. No signup.

This is a real, editable incident log, not a screenshot. Change a status, adjust a severity, add what happened. Your edits stay in this tab. When you want to keep one, a click makes it yours.

DateLocationTypeWhat happenedSeverityStatus

Sandbox only, edits don't persist. Want to keep your work? Start your 7-day free trial →

Four incident report templates, free to download

Each one ships as an .xlsx with realistic sample entries. No email gate; the download link is right on the card.

Incident Log: incident report template screenshot

Incident Log

DateLocationTypeSeverityDescriptionReported ByCorrective ActionAction OwnerStatus

The running register: one row per incident across a site or team, with type, severity, corrective action, owner, and status. Use it when you need the pattern view (what keeps happening, and where) plus a live count of open corrective actions, not just single-incident paperwork. The sample rows show a month of realistic warehouse and office entries.

Download .xlsx8 example rows
Workplace Incident Report: incident report template screenshot

Workplace Incident Report

SectionDetailCompleted ByStatus

The single-incident form, structured as sections you complete top to bottom: date and location, people involved, a factual description, immediate action, witnesses, root cause, and the corrective action with its due date. Use it when one event needs full documentation and a review trail, from first report through sign-off by a supervisor or safety officer.

Download .xlsx14 example rows
IT Incident Report: incident report template screenshot

IT Incident Report

Incident IDDateSystemSeverityUser ImpactRoot CauseResolutionOwnerStatus

For outages and service incidents: severity grade, user impact, root cause, and the fix, one incident per row with an owner and status. Use it when the audience is engineering plus stakeholders who want the impact story at a glance, and when your postmortems need a consistent register instead of scattered documents. Sample rows cover five realistic incidents.

Download .xlsx5 example rows
Safety Near-Miss Log: incident report template screenshot

Safety Near-Miss Log

DateAreaHazard TypeWhat Almost HappenedPotential SeverityReported ByPrevention StepStatus

Near misses are free lessons: the same causes as injuries with none of the harm, which makes them the cheapest safety data you will ever collect. This log keeps the reporting friction near zero (date, area, what almost happened, potential severity, prevention step) so patterns surface and get fixed before someone gets hurt.

Download .xlsx6 example rows

How to write an incident report that actually gets used

Record it the same day, in plain language

Details decay fast. Capture the who, what, where, and when while they are fresh, and write what a camera would have seen rather than conclusions: "truck rolled forward one meter while the chocks were not set" beats "driver was careless" in every later conversation, including the uncomfortable ones.

Separate the event from the cause from the fix

The three most useful columns in any incident record are the description (what happened), the root cause (why it could happen), and the corrective action (what changes so it cannot repeat). Keeping them separate stops the report from stopping at blame.

Give every corrective action an owner and a date

An incident report without an owned follow-up is a diary entry. The log variants here carry Action Owner and Status columns so every open action is visible until it closes, and nothing quietly expires in a drawer.

Review the log monthly for patterns

Single reports fix single problems. The log fixes systems. Sort by location or type once a month and the clusters announce themselves: the same dock, the same machine, the same shift. That is where the next corrective action should aim.

Keep reporting blame-free, or the log goes quiet

The fastest way to kill incident reporting is to punish the people who file it. If a near miss earns a lecture, the next one goes unreported and the log turns into fiction. Thank reporters publicly, aim corrective actions at systems rather than individuals, and treat a rising near-miss count as the culture working, not the site getting worse.

Incident report vs incident log: which one do you need?

The form documents one event deeply: sections for people involved, witnesses, immediate action, root cause, and sign-off. The log tracks every event shallowly-but-consistently: one row per incident with type, severity, and corrective-action status. Mature teams run both, and they feed each other: serious rows in the log get a full form attached, and every completed form adds a row to the log.

If you are choosing one to start with, start with the log. The habit of recording everything small builds the culture that makes the big reports honest.

The first 24 hours: a short incident response sequence

First, make it safe: stop the activity, help anyone affected, and secure the area so the situation cannot get worse. Nothing about documentation matters until this is done. Second, preserve the scene in facts: photos, the names of people involved and witnesses, and timestamps, before cleanup erases them. Third, open the report while memories are hours old rather than days old, filling the factual sections even if the root cause is still unknown.

Fourth, take the immediate corrective step that prevents a repeat tomorrow morning, and record it as such. The permanent fix can follow the investigation. The interim control (a cone, a sign, a disabled machine, a revoked credential) belongs in the report today. Fifth, notify whoever your rules require: a supervisor, a safety officer, an insurer, or an authority, depending on severity and jurisdiction. The report you started in step three makes every one of those conversations faster and more accurate.

The sequence matters because it fails gracefully: even if the investigation stalls, you have a protected scene, a factual record, an interim control, and a notified chain, which is a defensible position for the organization and a safer one for the team.

What incident reports look like by industry

Construction and logistics teams lean on the near-miss log and the workplace form: physical hazards, vehicle movement, and lifting events dominate, and the corrective actions are usually process rules or equipment changes. Manufacturing sites add machine and line columns so patterns localize to specific equipment. IT and software teams use the severity-graded incident report where "harm" is user impact and downtime, and the root-cause column carries the postmortem in miniature. Offices report less often but still need the log: slips, electrical issues, and security events do not announce themselves in advance.

All four templates here share the same skeleton (facts, cause, corrective action, owner, status) so a company running more than one kind of work can keep a consistent reporting culture while each team uses the shape that fits its risks.

Frequently asked questions

What is an incident report?

An incident report is the written record of an unplanned event that caused, or could have caused, harm to people, property, or operations. A useful one records the facts (date, time, location, people involved), a plain-language description of what happened, the immediate action taken, the root cause once known, and the corrective action with an owner and a due date. Its job is not paperwork; it is making the repeat less likely.

What should an incident report include?

Seven essentials: when and where it happened, who was involved and who witnessed it; what happened, described factually; injuries or damage, if any, the immediate response, the root cause. And the corrective action with an owner and a date. The workplace form template carries all seven as sections, and the log variants carry them as columns so they stay consistent across every entry.

How do you write a good incident description?

Write what a camera would have recorded, in the order it happened, without conclusions or blame. "Pallet jack was inside the trailer when the truck rolled forward about one meter, wheel chocks had not been set" gives an investigator everything. "Driver was careless" gives them nothing and starts an argument. Save causes for the root-cause field, where they belong.

What is the difference between an incident report and a near miss?

A near miss is an incident where the harm did not land: the load that fell where nobody stood, the two vehicles that stopped in time. Teams that record near misses in a simple log catch the same causes as injury reports while the price is still zero, which is why this page includes a dedicated near-miss log variant with the lowest possible reporting friction.

Do these templates satisfy legal reporting requirements?

Treat them as your working layer, not your compliance filing. Formal requirements vary by country, state, and industry, and some incidents must be reported to authorities on specific forms within specific windows. These templates keep the operational record complete and current, which also makes any formal filing faster. Check your local rules for what must be submitted and where.

How long should incident reports be kept?

Retention rules vary by jurisdiction and industry, and some record types carry mandated minimums measured in years, so check the requirements that apply to you. Operationally, keep the log itself forever: it costs nothing, and the multi-year view is where the slow patterns live, like the hazard that resurfaces every winter or the incident type that returns whenever staffing is thin. A living log with full history is also the fastest way to answer an auditor, an insurer, or your own "have we seen this before?" question.

Why keep the incident log in Wisegrid instead of a spreadsheet file?

A file goes stale in a drawer. The live version nudges action owners automatically when follow-ups go overdue, rolls open actions into a dashboard so the safety picture is current without anyone assembling it, and keeps one log everyone edits instead of four copies nobody trusts. The free downloads are yours either way.

Run it live instead of in a file.

The downloads above are yours either way. In Wisegrid the same template becomes a working sheet with owner contacts, status dropdowns, reminders, and dashboards. 7-day free trial, no credit card required.