Classic form
Bug report form that produces reports a developer can reproduce
A bug report is useful when someone else can make the bug happen, and most forms ask for a description and nothing else. This one asks for the steps as a numbered table, the expected and actual result as two fields, the environment as choices, and posts the whole thing to the issue tracker as JSON.
The form itself
A static copy of the finished form, exactly as it renders. Nothing here can be filled in or submitted, so read it as a reference and build your own from the button above.
Every field, and what it collects
The complete field list, in the order respondents meet it.
- One line summaryShort textRequired
- Where in the app?DropdownRequired
- Options: Dashboard · Invoices · Bank feeds · Reports · Settings · Mobile app · Other
- Steps to reproduceTableRequired
- Columns: What you did
- What you expectedLong textRequired
- What actually happenedLong textRequired
- How bad is it?Single choiceRequired
- Options: I cannot use the app · A feature is broken · Something is wrong but I have a workaround · Cosmetic
- Does it happen every time?Single choiceRequired
- Options: Every time · Most times · Sometimes · Once
- Browser or appDropdownRequired
- Options: Chrome · Safari · Firefox · Edge · iOS app · Android app
- Device and operating systemShort text
- Account emailShort textRequired
- Approximate time it happened, with timezoneShort text
- ScreenshotPhoto upload
- The whole screen, including the URL bar. Blur anything private first.
- Exports or capturesFile upload
- Up to 3 files, images or PDF. Plain text logs are not accepted as files; paste them below.
- Anything else, including pasted error textLong text
Question banks built on this form
The webhook payload, and what the tracker side needs
With the webhook add-on on, each submission fires one POST of JSON: an event name, a timestamp, the form's id and title, and the response with its answers keyed two ways, by field label and by field id. The receiving endpoint has ten seconds to answer and there is no retry, so the tracker side should accept immediately and process afterwards, a tiny function that acknowledges, then creates the issue with the summary as the title and the steps table, which arrives as an array, rendered into a numbered list. Redirects are not followed and only http and https are accepted, so point it straight at the final endpoint.
How to adapt this form
An internal QA version adds a build number field beside the browser dropdown and drops the account email, since QA knows its own accounts. A game studio replaces the where-in-the-app dropdown with level or mode and asks for a save file link, uploads being image and PDF only. A hardware version swaps environment for a serial number and firmware version pair. The four load-bearing fields survive every variant untouched: summary under 120 characters, steps one per row, expected, actual. Remove any of those and the form goes back to collecting descriptions.
What makes this form work
Steps arrive in order because the table forces order
Six numbered rows, one action each, starting from a fresh login. The difference between click, then, then in sequence and the same facts scattered through a paragraph is the difference between reproducing a bug in two minutes and emailing the reporter twice.
The 120 character summary is the issue title
The first field is capped at 120 characters, which is a workable issue title in every tracker. Whatever the webhook creates on the board is titled by the reporter, in the reporter's words, without an engineer rewriting it, and the cap is what makes that safe.
Severity is asked in sentences a user can stand behind
I cannot use the app is a fact the reporter knows; P1 is a judgement they cannot make. Four plain statements collect the honest signal, the team maps them to priority at triage, and nobody argues about whether their cosmetic bug was really a P2.
Questions people ask
What should a bug report contain?
The classics, and this form is shaped exactly on them: a clear one line summary, precise steps to reproduce, what you expected, what actually happened, and the environment it happened in. Mozilla's bug writing guidelines have said the same thing for two decades, because reports with those five parts get fixed and the rest get triaged into silence.
Why are the steps a table?
Because order is the evidence. A paragraph mixes setup, action and reaction into prose a developer has to untangle; a numbered table with one action per row forces the sequence out of the reporter's head. The six rows are fixed, and the paragraph under the table says three good rows are usually enough.
Can users attach a log file?
Not as plain text: uploads accept images and PDF only, so the form says so on the upload field and provides a paste field for error text instead. Pasted logs also arrive searchable in the tracker, which a screenshot of a terminal never is.
How does a submission reach the issue tracker?
Through the webhook add-on: one JSON POST per submission, answers keyed by field label, ten second timeout, no retry. The endpoint should acknowledge first and process after. The payload section above walks the shape and the sharp edges, including the absent retry, which is the one to design around.
Should you ask users for severity?
Yes, in words they can actually judge: cannot use the app, a feature is broken, workaround exists, cosmetic. Those map roughly onto P1 through P4, but the mapping is the team's call; the reporter is only ever asked about their own experience, which is the only thing they can honestly rate.
How do you stop duplicate reports?
You do not, at least not at the form. Duplicates are cheap to merge at triage and expensive to prevent at submission, and a duplicate is still evidence of frequency. A public status page quietly reduces them, because half of all duplicate reports are people checking whether you already know.
Build your own in about a minute
The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.
Make my bug report form that produces reports a developer can reproduceOther form examples
NPS survey with the score explained
Net Promoter Score is one question, and most surveys ruin it by adding nine more. This one is the question, one follow up, and a permission to reply, and the page shows how the number is worked out from the responses table.
Contact form template
A contact form gets worse with every field added to it. This one has six, and the two doing the real work are the subject dropdown that routes the message and the line printing the reply time where somebody can see it before they write. It states the phone number rather than hiding behind the form, and it does not sign anyone up to anything. Classic, because six fields on one screen is faster than six screens.
Appointment request form that reception confirms
A form is not a calendar, and pretending otherwise is how double bookings happen. This one asks for three preferred times in the patient’s own words, tells them reception will confirm one by text within two working hours, and collects the reason for the visit so the right length of appointment gets booked.
Want the steps in the builder? Read Automate your form with add-ons, then Form builder components. For everything this generator can do, see the form maker.
Written and checked by the OneCraft team. Last checked .