Bug report template builder
Engineering keeps sending tickets back for more detail, and the back and forth costs your customer days. Fill in nine fields, copy the report into your tracker, and the questions stop.
No sign-up. Runs in your browser. Copies as plain text, Markdown or Jira.
Your report
7 fields need filling in
For Zendesk, Freshdesk, Intercom, or any plain description box.
TITLE: Untitled bug report WHAT HAPPENED (not described) WHAT SHOULD HAPPEN (not described) WHERE (screen or module not named) STEPS TO REPRODUCE (none given) WHO IS AFFECTED (not stated)
Runs in your browser. Nothing you type is sent to us or stored.
The two fields that do most of the work
Where it happened narrows the search from a whole product to one area, which is the difference between an engineer reading one file and reading forty. The customer’s own message matters even more. A summary written for a human reader drops the exact error text and the record ids, and those are the strings that find the responsible code. Keep the raw message as well as your summary, never instead of it.
The optional ninth field, your best guess, is the cheapest one here. Plenty of reports that read like defects turn out to need a setting changed or a customer shown where to click, and flagging that in five seconds sends the ticket to the right person first time instead of after an engineer has spent an afternoon in code that was never wrong.
One report, one problem. If a customer raises three unrelated things in one message, file three. A report covering several problems gets worked on for whichever one is described most clearly, and the rest quietly fall off.
Filling this in by hand for every ticket is the part that does not scale. Watari reads the support ticket and its attachments, writes the structured report, points at the code responsible, and drafts the fix as a pull request. See how.
Frequently asked questions
What should a bug report always include?
What the customer saw, what should have happened instead, where in the product it happened, the steps you took, who is affected, when it started and how often, the customer’s own message pasted verbatim, and whatever evidence you have. A ninth field, your best guess at whether it is a bug or a setting, is optional and saves more time than it costs.
Why paste the customer’s own words instead of a summary?
A summary written for a human reader drops the exact error string, the record ids and the screen names, and those are precisely what locate the problem in the code. Keep the raw message as well as your summary, never instead of it, and keep it in whatever language the customer wrote in.
What if I cannot reproduce the issue?
File it anyway and say so. Write down what the customer did, in order, and note that you could not reproduce it yourself. "Happens for one account only" is a useful finding, not a gap: a problem confined to one account is usually a setting rather than a defect.
Does this tool send my bug details anywhere?
No. The report is assembled in your browser as you type. Nothing you enter is sent to Watari or stored, and there is no sign-up.
Why does the Jira output look different?
Jira’s description field uses wiki markup, not Markdown, so Markdown headings and quotes arrive as literal characters. The Jira option emits h3. headings and {quote} blocks so the report renders properly. Use Markdown for GitHub, Linear or Azure Boards, and plain text for Zendesk, Freshdesk or Intercom.
When a support ticket reports a bug, your engineers get a drafted fix.
Connect your help desk or your issue tracker, then GitHub or Azure DevOps. Watari maps each bug to the exact file and function in your code and drafts the fix as a pull request your CI checks.
14 days free. No card. Cancel any time.