Bug report form
A bug report form gets structured information from whoever encounters the bug — reproduction steps, what they expected, what actually happened — instead of an urgent message with no context. Your team can sort by severity and reproduce from the steps given, rather than asking clarifying questions first.
The form beside this text is live. Fill it in and submit it — it validates exactly as it would for a real respondent, and saves nothing.
Severity sorting prioritises triage
A severity dropdown means critical bugs surface first in a CSV export or Slack feed, rather than getting read in arrival order.
Reproduction steps save debugging time
Step-by-step "what I did" and "expected versus actual" fields let your team reproduce the bug locally instead of guessing what the user meant.
This one uses file uploads, which is a paid feature — you can build and edit it on the free plan, but saving it needs an upgrade.
No card required.
Bug Report
Live previewHow to build this form
5 steps in the editor.
- Add text fields for the reporter's name and email, so you can ask follow-up questions.
- Add a dropdown for severity — critical, major, minor, cosmetic — so reports can be sorted by impact.
- Add two textareas: what the user did, and expected versus actual behaviour.
- Add an optional text field for browser, OS or device, and an optional file upload for a screenshot.
- Export to CSV or send each report to Slack so a bug does not get lost in email.
Fields in this form
7 fields, using 5 of the 19 field types available.
| Question | Field type | Required |
|---|---|---|
| Your name | Short text | Yes |
| Yes | ||
| Severity | Dropdown | Yes |
| What did you do? | Long text | Yes |
| Expected versus actual | Long text | Yes |
| Browser, OS, or device (optional) | Short text | Optional |
| Screenshot (optional) | File upload | Optional |
What goes wrong with this form
Specific to a bug report form, not general advice about forms.
Asking for a stack trace or debug logs in the form
Most users will not know how to get them, so asking means most reports land incomplete. Ask for reproduction steps instead; your team can gather logs themselves.
No severity field means all bugs look the same
Without one, a critical bug and a cosmetic typo queue up equally. A dropdown lets you triage by impact before reading each report.
Skipping the "expected versus actual" field
What the user thought would happen is as important as what did happen — that gap is often the bug. Ask both up front to save a round of follow-up questions.
Questions about this form
What should a bug report include?
The reporter's name and email, the severity level, exactly what they did to trigger it, what they expected, and what actually happened instead. A screenshot or environment detail helps but is not required.
How do I prioritise bug reports?
Export to CSV and sort by the severity dropdown, or set up Slack delivery so critical reports surface in a channel immediately.
Do I need the reporter's email?
Only if you want to ask follow-up questions; many teams keep it optional so users can submit urgent bugs without stopping to fill in details.
This one uses file uploads, which is a paid feature — you can build and edit it on the free plan, but saving it needs an upgrade.