Form · Business
Software incident report form template
Written for the person who notices a problem, not the engineer who fixes it, so it asks plain questions and turns them into a triage-ready record. A critical report asks for a number the on-call engineer can ring right away, and an incident that has already stopped is asked how it resolved.
Try it live
Try it as a respondent
Every question, and where it leads
The conversation
What a respondent is asked, in order.
Something not working? Tell us what you're seeing and we'll get the right person on it.
Who is reporting this?
Which system, app or service is affected?
Where is it happening?
When did it start, as best you know?
How bad is it right now?
What number can the on-call engineer reach you on right now?
Is it still happening?
What made it stop, and roughly when?
What exactly are you seeing?
Who is affected?
What is it getting in the way of?
What have you or anyone else already tried?
Add a screenshot, recording or log file if you have one.
Ends with
Incident logged 🛠️
The flow
Where each answer leads. Every route here is editable once the form is yours.
Contact info
Short text
Single select
Date
Single select
Phone
Yes / No
Long text
Long text
Single select
Multi select
Long text
File upload
What this template uses
- Contact info
- Short text
- Single select
- Date
- Phone
- Yes / No
- Long text
- Multi select
- File upload
- 6 branches
Questions to consider
- What counts as critical for your service, and does the wording of the severity options match your incident policy?
- Is there an urgent channel, like an on-call phone line, that people should use instead of the form for outages?
- Which systems do people most often report? A dropdown of them may beat a free-text answer.
- Who reads new reports, and during which hours?
How to use the responses
Triage from the severity and who-is-affected answers first, then assign an owner. Critical reports carry a phone number, so ring back rather than replying by email. Keep the start time and the resolution answer for the incident timeline, and export the reports to CSV each month to see which services break most and whether the same impact keeps coming up.
How to customize and share it
- 1Rename the severity levels to match your incident process, keeping the critical option first so it routes to the callback question.
- 2Replace the impact options with the parts of your product people depend on most.
- 3Share the link in your help desk, status page and internal chat so reports land in one place, and review them in the dashboard.
Frequently asked questions
What should a software incident report include?
The affected service, when it started, how severe it is, who is affected, what the person saw and what has been tried. A screenshot or error message makes it much faster to diagnose.
Is an incident report the same as a bug report?
Not quite. An incident report records a disruption to a running service, while a bug report describes a defect that may never have caused an outage.
How do I handle critical incidents reported through a form?
Make sure someone is watching for them. This form asks critical reporters for a phone number so the on-call engineer can call straight back.
Can non-technical staff use this form?
Yes. The questions are in plain language, and in the chat an AI follow-up asks for more detail when a description is too vague to act on.