Bug report template and builder
A structured form for the fields a developer needs, a quality check on the four things that get bugs rejected, and export to Markdown, Jira wiki markup or plain text.
Ten fields in, a formatted report out — with automatic step renumbering and a quality check before you file it.
Open the tool — free, no signupWhat this tool does
You fill in ten fields: title, severity, priority, reproducibility, environment, build, steps to reproduce, expected result, actual result, and additional info. It formats those into a report, runs four quality checks, and exports as Markdown, Jira wiki markup or plain text. The steps field takes one step per line and renumbers automatically, stripping any numbering you typed — so pasting from a scratch note does not produce "1. 1. Log in".
What a good bug report contains
A title that stands alone. A developer scanning a backlog should understand the bug from the title without opening it. "Checkout returns 500 error when cart contains more than 10 items" states what broke, where, and under what condition. "Checkout bug" states nothing. The checker flags titles under 15 characters.
Steps that start from a known state. Begin at login or a specific URL, not from wherever you happened to be. Each step is one action. If a step needs particular data — a specific user, a specific cart — say so in the step. Developers close bugs they cannot reproduce, and that is the most common reason a genuine defect gets rejected.
Expected and actual, both stated. The gap between them is the bug. With only the actual result you have described an event, not a defect, and left the developer to guess what correct behaviour was. This is where disagreements about whether something is a bug at all get settled.
Environment. Browser, OS, device and build. It is the first thing a developer asks for, and a bug that only reproduces on one of them is a different bug from one that reproduces everywhere.
Severity that matches the description. The tool shows the definition for whatever you selected: critical means unusable, data loss or a security breach with no workaround; high means a major feature broken with a painful workaround; medium means partially broken with a reasonable workaround; low means cosmetic. Mismatched severity is the fastest way to lose a developer's trust — when everything is filed critical, nothing is.
Common mistakes
Merging several bugs into one ticket. One defect per report. Bundled bugs get partially fixed and closed.
Interpretation in place of observation. "The API is broken" is a theory. "POST /orders returns 500 with this body" is an observation. Report what you saw; put the theory in additional info.
Steps that assume your context. Feature flags, account state, seeded data and locale settings are invisible to the reader unless stated.
Missing the request ID or timestamp. For anything server-side, this is what lets a developer find your exact failure in the logs. It often turns a two-day investigation into ten minutes.
Everything is generated in your browser; nothing you type is sent anywhere.
Frequently asked questions
How do you write a good bug report?
Give it a title that describes what broke, where and under what condition. Add numbered steps from a known starting state, both the expected and the actual result, the environment and build, and any log or request ID. Severity should match the impact you described.
What is the difference between severity and priority?
Severity is how badly the defect breaks the product; priority is how soon it should be fixed. They are set by different concerns — severity by technical impact, priority by business need — so a low-severity typo on a pricing page can legitimately be top priority.
Can I export the report to Jira?
Yes. The Jira option outputs wiki markup — headings, bold fields, and numbered steps — which pastes directly into a Jira description field. Markdown and plain text are also available, with copy and download buttons.
Why do developers reject valid bugs?
Most often because they cannot reproduce them. Missing steps, an unstated starting state, no environment, or data that only exists in your session are the usual causes. An intermittent bug should also be labelled as one, not presented as always occurring.