Incident report template

An incident report is the formal record of an unplanned interruption or a drop in the quality of an IT service. It describes the nature and scope of what happened, the impact on users and the business, the initial response and resolution effort, and the root-cause analysis with the corrective actions that follow. This incident report template gives every incident your on-call team handles the same shape: the same severity scale, the same timeline structure, and the same set of post-incident fields, so nothing important gets skipped at 2am. Copy the template above straight into a Jira issue, or read on for what to capture, the SEV1 to SEV4 severity levels, the blameless postmortem, and how to turn the structure into a reusable template with Process Templates for Jira.

What this template captures and why

When each responder writes the record their own way, the data is hard to compare and the retrospective turns into archaeology. A standardized incident management template means every incident is documented consistently and in an organized way, which makes outages easier to track, prioritize, and learn from. Just as important: it removes the “what do I write where” question during the response itself, so people can focus on restoring service instead of formatting a ticket.

Field-by-field breakdown

• Summary: one line a colleague can scan in a status channel, naming the symptom, the affected system, and the window. Example: “Login outage on api.example.com between 14:05 and 14:38 UTC”.
• Description: the full account of the incident, including relevant context, symptoms, and the exact error messages observed. This is where you paste the alert text and the first observations.
• Severity: a dropdown for SEV1 through SEV4 so escalation paths and SLAs trigger off a single, consistent value.
• Impact: a dropdown ranging from High to Low describing the effect on business operations.
• Affected systems: the list of services, hosts, and client versions involved, for example api.example.com and the mobile app from v3.4 onward.
• Date / time: when the incident started, including the time zone. Always record UTC alongside local time so a distributed team reads the timeline the same way.
• Timeline: a chronological log of detection, paging, mitigation, and recovery. A clean timeline is the single most useful artefact in the later review.
• Root cause: the underlying reason the incident occurred, if known. Keep it factual and blameless.
• Resolution: what actually fixed it, including any workarounds applied before the permanent fix landed.
• Customer-facing impact: a short paragraph quantifying who was affected and for how long. This text is what you reuse for customer communications and the public status page.
• Lessons learned: the recommendations that prevent a repeat. Each one should be specific enough to become a follow-up ticket.
• Related issues: the Epics, Stories, and follow-up Tasks linked to this incident so the corrective work is traceable.

Incident severity levels: SEV1 to SEV4

Severity is the single field that drives the whole response, so the scale has to mean the same thing to everyone. This template uses four levels, ordered from most to least urgent:

• SEV1, critical. A business-wide outage with no workaround. Core functionality such as login or checkout is down for most or all users. SEV1 pages the on-call engineer immediately, opens a war room, and starts the customer-communication clock. The TLS-certificate example above is a SEV1.
• SEV2, major. A core service is significantly degraded for many users, but a partial workaround exists or the blast radius is limited to one region or plan. SEV2 still pages on-call, but does not always need a war room.
• SEV3, minor. A non-critical feature is broken, or a small subset of users is affected, with an easy workaround. SEV3 is handled in business hours and tracked, not escalated.
• SEV4, low. A near miss, a cosmetic defect, or a degradation with no user-visible effect. SEV4 is logged so the pattern is visible later, but it does not interrupt anyone’s day.

Pairing Severity with the separate Impact field keeps the two judgements honest: severity captures the technical blast radius, impact captures the business cost. A SEV2 that hits your largest customer can carry High impact, and recording both stops a low-severity but high-cost incident from being under-prioritized.

Best practices

• Fill the severity and timeline fields during the incident, not after. Memory degrades fast and timestamps drift.
• Keep the root cause blameless. Name the system and the failure mode, not the person.
• Record times in UTC. A distributed on-call team should never argue about whose 14:05 it was.
• Turn every lesson learned into a linked follow-up issue rather than a paragraph nobody actions.
• Reuse the customer-facing impact text verbatim in your status-page update so internal and external accounts never diverge.

Incident timeline best practices

The timeline is the backbone of every later review, and it is only useful if it is captured as events happen. A few habits keep it trustworthy:

• Log in UTC, one event per line. Each entry is a timestamp plus a single fact: an alert, a page, a hypothesis, a mitigation, a recovery. Resist editorializing during the incident; record what happened and move on.
• Capture the four anchor moments. Time of detection, time of acknowledgement, time of mitigation, and time of full recovery. These four stamps give you the metrics that matter later: time to detect and time to resolve.
• Note decisions, not just actions. “14:22 decided to roll back rather than hotfix” explains the response far better than the rollback line alone, and it is exactly the kind of detail the postmortem needs.
• Distinguish mitigation from resolution. Restoring service with a workaround at 14:38 is mitigation; rotating the certificate so it cannot recur is resolution. Mark both so the timeline tells the honest story.
• Freeze it at the end. Once the incident closes, the timeline becomes the source of truth for the review. Append corrections in the postmortem rather than rewriting history.

The post-incident review: a blameless postmortem

The postmortem, or post-incident review, is where an incident stops being firefighting and becomes learning. Written well, it is a blameless root-cause analysis: it explains how the system allowed the failure, not who pushed the button. This postmortem template lives on the same Jira incident issue and reuses the fields you already filled.

A blameless RCA assumes everyone acted reasonably with the information they had at the time. The questions it asks are systemic:

• What happened, in sequence? The frozen Timeline field is the answer. Read it as a narrative from detection to recovery.
• Why did it happen? Drive the Root cause past the first symptom. “Logins failed” is a symptom; “the TLS certificate expired because nothing monitored its expiry” is a root cause. Asking “why” until you reach a process or systemic gap is the heart of RCA.
• Why did it take this long to detect and resolve? Compare the four anchor timestamps. A slow detection points at a monitoring gap; a slow resolution points at a runbook or access gap.
• What stops it recurring? Every answer here becomes a Lessons learned item, and every Lessons learned item becomes a linked follow-up ticket with an owner and a due date.

Keeping the review blameless is not politeness, it is accuracy. The moment a review assigns blame, people stop volunteering the details that make the next incident shorter. Name systems and failure modes; leave names out.

A strong report versus a weak one

A weak incident report reads: “API was down for a while, fixed now.” There is no severity, no timeline, no affected-systems list, and nothing the next on-call engineer can learn from.

A strong report fills the structure: severity SEV1, affected systems api.example.com and the mobile app from v3.4 onward, timeline 14:05 alert triggered, 14:08 on-call paged, 14:30 rollback initiated, 14:38 service restored, root cause expired TLS certificate on the auth gateway, customer-facing impact ~12,000 users unable to log in for 33 minutes, and a lessons-learned list that becomes three linked follow-up tickets. The difference is not effort during the incident, it is having the fields ready before the pager goes off.

How to use this template in Jira

Capturing this structure by hand on every Jira incident is exactly the busywork a template removes.

1. Install Process Templates for Jira from the Atlassian Marketplace and open your Jira Service Management project. It is free for up to 10 users.
2. Build an Incident issue with these fields and save it as a template from the issue menu. See creating issue templates for the walkthrough.
3. Turn Severity and Impact into variables, along with Affected systems, using template variables so responders pick values at create time instead of editing prose.
4. Create the incident from the template when an alert fires with creating issues from templates, so the structure is in place before anyone starts typing. Use smart values to auto-stamp the reporter and the date, and keep the corrective work linked back to the incident.

Frequently asked questions

What should a Jira incident report include? A strong incident report includes a one-line summary, a full description with the exact error messages, a severity from SEV1 to SEV4, the business impact, the affected systems, the date and time in UTC, a chronological timeline, the root cause, the resolution, the customer-facing impact, lessons learned, and links to follow-up issues.

What do the SEV1 to SEV4 severity levels mean? SEV1 is a critical, business-wide outage with no workaround. SEV2 is a major incident degrading a core service for many users with a partial workaround. SEV3 is a minor incident affecting a non-critical feature or a subset of users. SEV4 is a low-impact issue or near miss with no user-visible effect. The level drives the escalation path and the SLA clock.

What is the difference between an incident report and a postmortem? The incident report is the live record captured during the response: summary, severity, timeline, and resolution. The postmortem, or post-incident review, is the blameless analysis written afterward that explains the root cause and turns lessons learned into linked follow-up tickets. Both live on the same Jira incident issue.

How do I create a reusable incident report template in Jira? Install Process Templates for Jira, build one model Incident issue with the fields on this page, save it as a template, then turn Severity, Impact, and Affected systems into variables so responders pick values when an alert fires instead of formatting a ticket from scratch.

Related templates

Pair the incident report with the rest of your service workflow: the IT support request template, the Request for new software template, the change management template for the controlled fix that follows an incident, and the Bug template for the defects an incident often uncovers. Or browse the full template library for matching formats across software, ITSM and support work.