Incident report template

An incident report is a structured internal record of an event that disrupted — or could have disrupted — the normal operation, security, or availability of a service. An IT incident report template gives that record a fixed structure, so nothing is missed while the incident is still live.

For an IT or SaaS team, that might include:

• A complete or partial service outage
• Elevated error rates or severe performance degradation
• A failed production deployment
• Database or infrastructure failure
• A third-party provider outage or security incident
• Any event that put availability at risk, even without a full outage

The report captures the known facts, operational response, impact, timeline, communications, and follow-up work tied to that incident.

The term can also refer to workplace accidents or physical safety incidents — this template is for technology and service-management incidents, not physical ones.

Not every warning, bug, or brief interruption needs a formal report — define your own threshold based on customer impact, risk, and internal policy. A report is usually warranted when an incident:

• Causes a significant customer-facing outage
• Breaches or threatens an SLA or SLO
• Requires coordination across multiple teams, or customer/public communication
• Involves a potential security or privacy issue
• Causes material financial or operational impact
• Repeats a previous failure or requires substantial corrective work

Lower-severity incidents can use a shorter version of the same template — just a summary, impact, timeline, and follow-up actions. What matters is that the threshold is defined in advance, not debated mid-incident.

Incident identification

Give the incident a clear, descriptive title that names the service and the customer-visible symptom — "Elevated API error rates caused by database connection exhaustion," not "API issue." An incident ID makes it easy to cross-reference the ticket, status page, and postmortem later.

Severity

Severity communicates urgency and impact. A simple model:

The exact thresholds matter more than the labels — tie each level to clear impact criteria and response expectations.

Important times

Record when the incident started, was detected, was mitigated, and was resolved. These timestamps let you measure time-to-detect, time-to-acknowledge, and time-to-resolve, and separate the customer-facing impact window from the internal response process.

Incident summary

A few factual sentences: what happened, what was affected, what caused it, and how service was restored. For example:

Between 14:03 and 14:31 UTC, customers experienced elevated error rates on the public API. The incident was caused by database connections reaching their configured limit. The team restored service by terminating the affected queries and increasing connection capacity.

Save the deeper technical explanation for the cause section.

Customer and business impact

Describe consequences, not just symptoms — "customers couldn't complete checkout," not "CPU usage hit 100%." Cover which services and customers were affected, how long it lasted, whether data was lost or delayed, and whether an SLA or SLO was breached. Quantify where you can, and say "unknown" rather than guess.

Detection

How did the team find out — an alert, a customer report, a support ticket? If customers noticed before monitoring did, that's a detection gap worth flagging here.

Response and mitigation

Summarize the actions that changed the course of the incident — rollbacks, failovers, capacity changes, workarounds — and the reasoning behind the key decisions, especially where responders had to choose between options carrying different risks.

Incident timeline

A chronological, factual account of what happened, in one clearly stated timezone. Don't rewrite it later to look more orderly than it was, and don't copy in an entire chat log — summarize what materially affected the investigation, response, or communication.

Communications

Link to what was said and where — internal updates, status page, customer emails, support guidance — rather than duplicating it. Internal reports can include details (infrastructure, employee names, provisional theories) that shouldn't appear in a public update.

Cause and contributing factors

Clearly separate symptoms, suspected causes, confirmed causes, and contributing factors — don't force a single "root cause" before the investigation is done. A failed deployment might be the trigger, while weak testing and missing alerts are what let it become an outage.

Follow-up actions

Every action needs an owner and, for high-priority items, a due date. "Improve monitoring" is an intention; "add an alert for connection-pool utilization above 80%, owned by Platform Engineering, due September 15" is an action.

The following simplified example shows how the template might be completed for a SaaS outage.

Incident details

Incident title: Elevated API errors caused by database connection exhaustion Incident ID: INC-2026-017 Severity: SEV-2 Status: Resolved Incident owner: Platform Engineering Incident commander: On-call engineering lead

Important times

Incident started: 14:03 UTC Incident detected: 14:07 UTC Incident acknowledged: 14:09 UTC Mitigation started: 14:18 UTC Service restored: 14:31 UTC Incident resolved: 14:45 UTC

Summary

Between 14:03 and 14:31 UTC, customers experienced elevated error rates when using the public API. A group of long-running database queries exhausted the available connection pool. Responders terminated the affected queries and temporarily increased connection capacity, restoring normal API performance.

Impact

Approximately 18% of API requests returned errors during the incident. Dashboard access and status-page availability were unaffected. No data loss or corruption was identified.

Detection

The incident was detected by an alert for elevated API error rates. The database connection pool did not have a dedicated saturation alert.

Timeline

Cause

A set of long-running analytical queries consumed a large percentage of the production database connections. The remaining capacity was insufficient to handle normal API traffic.

Contributing factors

• No alert existed for database connection-pool saturation.
• Analytical workloads shared database capacity with customer-facing requests.
• Query timeout limits were higher than necessary.
• The relevant operational runbook did not include connection-exhaustion diagnostics.

Follow-up actions

An incident report isn't the only record an incident produces — usually it's just the first.

A postmortem builds on the incident report rather than reconstructing the event from scratch, and an RCA is usually one input to the postmortem rather than a replacement for it. A public status-page update is a fourth, separate thing entirely — written for customers, not the internal team, and never the unedited internal report.

See our root cause analysis template for the next step; the postmortem template is coming soon.

• Record facts as they happen, in one consistent timezone. Reconstructing a timeline days later, or mixing timezones, produces an unreliable record.
• Separate facts from assumptions. Mark suspected causes as suspected until evidence confirms them.
• Describe impact in customer terms, not just technical symptoms. "Customers couldn't check out," not "CPU hit 100%."
• Preserve the reasoning behind key decisions. Why a rollback, failover, or workaround was chosen, not just that it was.
• Avoid blame. Focus on what let the incident happen or made it worse, not who made the change.
• Give every follow-up action an owner, and a target date for high-priority ones.
• Link out to evidence instead of copying it in — dashboards, logs, comms, deployments, tickets.
• Review before closing. Confirm impact, timeline, and actions are accurate; get sign-off for significant incidents.
• Treat a consistently completed report as your audit trail. It's useful evidence for SOC 2 reviews, ISO 27001 audits, and customer security questionnaires, without needing a dedicated compliance process.

How do you write an incident report?

Start from a template so nothing gets missed under pressure. Capture the title, severity, and key times as soon as they're known; fill in the summary, impact, and timeline as facts settle; and leave cause, contributing factors, and follow-up actions open until the investigation catches up.

What is the proper format for an incident report?

There's no single mandatory format, but a useful one covers: identification (title, ID, severity), key timestamps, a factual summary, customer and business impact, detection, response, a timeline, communications, cause, and follow-up actions. The template above uses that structure.

What are the core elements of an incident report?

At minimum: what happened, when, how it was detected, who and what was affected, how the team responded, how service was restored, what was communicated, and what work remains. Everything else supports answering those questions.

Is an incident report required for every outage?

No. Define thresholds in advance based on customer impact, severity, and risk — a brief blip might only need a ticket, while a major outage or security event usually warrants a full report.

Does an incident report replace a postmortem?

No. The report is the factual record; the postmortem is the deeper analysis of why it happened and what to change. Low-severity incidents may only need the report — major or recurring ones usually get both.

The best time to decide how incidents will be documented is before one occurs. Define what counts as an incident, which severities require a report, who owns it, where it's stored, and when a postmortem is required — so responders aren't debating documentation mid-incident.

A well-designed incident report shouldn't add administrative overhead during an outage. Used consistently, it becomes more than a record of one failure — it helps teams coordinate, communicate, and improve reliability over time.

The structure of this template follows what teams with public engineering handbooks require in their incident records. They differ mostly in who keeps the record and which incidents get a written review afterwards.