Product · free template

Incident Postmortem Form

Structured post-incident review covering severity, timeline, impact, root cause, action items and customer comms.

A ready-to-use technology, saas & dev form for engineering, IT and product teams: 18 questions, 4 pages, 4 conditional rules.

Questions: 18
Pages: 4
Layouts: classic · card
Conditional rules: 4
Typical time: 7 min

Preview it in the gallery

Searches this template answers

Live preview and test console

This is the real form. Answer it to test the 3 conditional rules — nothing is sent or stored.

Page 1 of 4 — Incident identification

Every question on this page is currently visible.

What happens after submit: nothing is stored in this preview. On your own copy, every response triggers an instant email notification and lands in your response dashboard, ready to export or forward.

Happy with it? Take a copy into your workspace — every question, rule and setting comes with it.

Who this template is for

Incident Postmortem Form is built for engineering, IT and product teams who need to route technical requests with the context needed to triage them.

Engineering, IT and product teams working in technology, saas & dev.
Teams who need to route technical requests with the context needed to triage them without writing code or paying for a custom build.
Anyone replacing vague reports that can't be reproduced or prioritised with one structured record per enquiry.
Respondents are users, testers and internal stakeholders — the form asks them 18 questions across 4 screens.
Mobile-heavy audiences, thanks to the one-question-per-screen card layout.

Why this form is useful

It removes the cost of vague reports that can't be reproduced or prioritised and turns each submission into a record your team can act on immediately.

8 questions are required, so submissions arrive complete instead of needing a follow-up email.
It accepts a document or photo upload as evidence.
It pins the request to a specific date.
It scores satisfaction on a consistent scale.
It captures a numeric value you can filter and sort on.
Conditional logic hides 4 questions until they are relevant — shorter forms convert better than long ones.
Splitting the form across 4 pages keeps each screen short and shows respondents how much is left.
Every response is stored, searchable and exportable, so nothing depends on one person's inbox.

How to use this template

From copy to live form is a few minutes of work, and every step is reversible.

1Press “Use this template” — a fresh copy of Incident Postmortem Form lands in your workspace, ready to edit.
2Rename or delete any question, and change what is required. Nothing here is fixed.
3Open Notifications and add the email addresses that should be alerted on each submission; add an auto-reply to the respondent if the form collects an email address.
4Check the upload limits on the file question so respondents can attach what you actually need.
5Publish it, then either share the link directly or paste the embed snippet into your site — the embedded form resizes to fit and loads no marketing or advertising trackers.
6Watch responses land in Submissions, where you can filter, label and export them to CSV or PDF.

Logic and conditions blueprint

Exactly how this form behaves as it is answered — 4 conditional rules ship with it.

Features advanced show logic: if “Were customers affected?” is Yes, the form dynamically exposes “Was a status page update or customer notification sent?”. Otherwise that question never appears.
Features advanced show logic: if “Were customers affected?” is Yes, the form dynamically exposes “Approximately how many customers were affected?”. Otherwise that question never appears.
Features advanced show logic: if “Was a status page update or customer notification sent?” is No, the form dynamically exposes “Is a customer follow-up still owed?”. Otherwise that question never appears.
Features conditional validation: if “Severity” is one of Sev1 — critical, Sev2 — major, “Underlying contributing factors” becomes mandatory before the form can be sent.
All 4 rules are editable in the Logic tab, and the built-in checker warns about rules that contradict each other.

About this template

A postmortem is only useful if it is filled in consistently, and this form gives every incident the same shape so reviews are comparable over time. It opens with identification — the incident name, severity level and who is filing the report — because severity determines how much scrutiny the rest of the document needs. A timeline section asks for detection time, the time the team started responding, and the time service was restored, which together produce the detection and resolution windows most reliability teams track. An impact section asks which services or features were affected and, separately, whether customers were affected and roughly how many, since technical impact and customer impact don't always match. The root cause section deliberately separates the immediate trigger from the underlying contributing factors, because treating the two as the same question tends to produce reports that stop at 'a deploy went out' rather than digging into why the deploy wasn't caught earlier. A customer-communications branch only appears when customers were affected, asking whether a status page update or direct notification was sent and whether a follow-up message is still owed. The closing page captures concrete action items with an owner for each, so the postmortem produces assignments rather than just a narrative.

What this form asks

Every question is editable — rename it, make it optional, or delete it entirely.

Page 1 — Incident identification

Incident name or IDrequired
Severityrequired
Report filed byrequired
Date of incidentrequired

Page 2 — Timeline and impact

Time detected
Time response started
Time service was restored
Services or features affectedrequired
Were customers affected?required
Approximately how many customers were affected?

Page 3 — Root cause

What was the immediate trigger?required
Underlying contributing factors
How effective was the initial response?

Page 4 — Customer communication and action items

Was a status page update or customer notification sent?
Is a customer follow-up still owed?
Action items and ownersrequired
Target date for action items to be complete
Attach logs, graphs or supporting evidence

18 questions in total.

How the form changes as it's filled in

This template ships with 4 conditional rules, grouped into 3 behaviours driven by 3 questions. Everything below is already set up — edit or delete any rule once the template is in your workspace.

Driven by “Were customers affected?”

Reveals questions
If “Were customers affected?” is Yes, the form reveals “Was a status page update or customer notification sent?” and “Approximately how many customers were affected?”.

Driven by “Was a status page update or customer notification sent?”

Reveals questions
If “Was a status page update or customer notification sent?” is No, the form reveals “Is a customer follow-up still owed?”.

Driven by “Severity”

Makes answers required
If “Severity” is one of Sev1 — critical, Sev2 — major, “Underlying contributing factors” becomes required before the form can be submitted.

Set it up step by step

1
File it while the timeline is fresh
Draft the timeline section within a day of resolution — exact detection and response times get harder to reconstruct accurately after that.
2
Push past the immediate trigger
Keep the trigger and contributing-factors fields separate in review; a postmortem that only names the trigger tends to miss the systemic fix.
3
Track action items to completion
Review the action-items list at a fixed interval after the postmortem — an unassigned or overdue item is a strong predictor of repeat incidents.
4
Close the customer-comms loop explicitly
Don't let 'is a follow-up still owed' go unanswered; an unresolved yes here should block the postmortem from being marked complete.

Mistakes to avoid

Stopping at the immediate trigger without documenting the contributing factors that let it happen.
Leaving action items without a named owner, so nothing gets done after the meeting.
Skipping the customer-impact section for incidents that were technically resolved quickly but still affected users.

What it pairs with

Most teams don't run this form on its own. These are the forms and systems it sits next to.

Software Bug Report Form
Vendor Security Questionnaire
Feature Request Submission Form

What to do with the responses

Assign and track each action item to completion, share the summary with affected teams, and close out any owed customer follow-up before archiving the report.

Works in both layouts

Browse classic templates Browse card templates

Forms that overlap this one

These pages cover the same subject ground as the incident postmortem form, matched on the words people actually search for.

Frequently asked questions

How is this different from the Software Bug Report Form?

A bug report describes a single defect from a user's point of view. This postmortem documents the incident response and root cause after the issue has already been resolved.

Do minor (Sev4) incidents need a full postmortem?

Many teams use a lighter version for Sev3/Sev4 incidents — the contributing-factors field is only required here for Sev1 and Sev2 to keep lower-severity reviews fast.

Who should file the report?

Typically the incident commander or the engineer who led the response, ideally with input from anyone else who was paged.

What happens to the action items after the form is submitted?

That depends on your workflow — many teams copy the action items into their issue tracker and use this form as the source record for the review itself.

Is the Incident Postmortem Form template free to use?

Yes. You can preview and test Incident Postmortem Form on this page without an account, and take a copy into your own HelloForms workspace on the free plan. There is nothing to install and no card required to publish it.

What does the Incident Postmortem Form template ask for?

It asks 18 questions across 4 pages, 8 of which are required. Every question is listed in full further down this page, and each one can be renamed, reordered, made optional or deleted after you copy the template.

Can I edit the Incident Postmortem Form form after copying it?

Yes — the copy is entirely yours. Change wording, add or remove questions, switch between the classic and card layouts, restyle it to match your brand, and set who gets notified on each submission.

How does the conditional logic in this technology, saas & dev form work?

4 conditional rules ship with the template: Features advanced show logic: if “Were customers affected?” is Yes, the form dynamically exposes “Was a status page update or customer notification sent?”. Otherwise that question never appears. Features advanced show logic: if “Were customers affected?” is Yes, the form dynamically exposes “Approximately how many customers were affected?”. Otherwise that question never appears. Features advanced show logic: if “Was a status page update or customer notification sent?” is No, the form dynamically exposes “Is a customer follow-up still owed?”. Otherwise that question never appears. All rules are editable in the Logic tab.

Where do responses to the Incident Postmortem Form form go?

Submissions land in your workspace under Submissions, where you can search, filter, label and export them to CSV or PDF. You can also email a notification to your team on every submission and send the respondent an auto-reply.

Can I embed the Incident Postmortem Form form on my own website?

Yes. Publish the form and paste the embed snippet into any page or share the direct link. The embedded form resizes to fit its container and loads no advertising or marketing trackers inside the iframe.

Can respondents upload files?

Yes. This template includes a file upload question, so respondents can attach documents or photos with their answers. You can adjust the accepted file types and size limits on that question.

More forms teams pair with the incident postmortem form.

Related categories

All Technology, SaaS & Dev templates