Guide
Bug report template
"It doesn't work" is the most common bug report, and the least useful one. A good report answers the questions a developer would otherwise have to ask you, before they ask them. Here's a template you can copy into any tool, and the thinking behind each field.
The template
Title: [what's broken, in one line]
What happened:
[what you saw, in plain words]
What you expected:
[what should have happened instead]
Steps to reproduce:
1.
2.
3.
Where:
- Page/URL:
- Browser and version:
- Operating system:
- Screen size (if layout-related):
- Account or role (if it matters):
Severity: [blocks work / annoying / cosmetic]
Extra:
[screenshot, console error, or anything else that helps]Why each field earns its place
- Title is searchable later. "Checkout button doesn't work on Safari" beats "bug on checkout page."
- What happened vs what you expected separates the symptom from the assumption. Sometimes the "bug" is a misunderstanding, and this makes that obvious fast.
- Steps to reproduce is the single most skipped field, and the one that turns "can't reproduce" into a fixed bug. If you can't write exact steps, you probably need to look again before reporting.
- Where (browser, OS, screen size) rules out "works on my machine" as the first reply. Half of visual bugs are browser-specific.
- Severity helps whoever triages decide what to drop everything for and what can wait a sprint.
A filled-in example
Title: Checkout button doesn't work on Safari
What happened:
Clicking "Place order" does nothing. No error, no spinner, nothing.
What you expected:
The order should go through and show a confirmation page.
Steps to reproduce:
1. Add any item to the cart.
2. Go to checkout, fill in valid card details.
3. Click "Place order."
Where:
- Page/URL: /checkout
- Browser and version: Safari 18.1
- Operating system: macOS 15.1
- Account or role: any, tested as a guest checkout
Severity: blocks work (nobody on Safari can buy anything)
Extra:
Works fine on Chrome. No console error visible, but I didn't check devtools.What this template can't give you
Even a careful report like the one above is missing things a developer will ask for next: the actual console error, what the network request returned, what the page looked like a few seconds before it broke. Someone has to go back, reproduce it again, and dig those out by hand, or the back-and-forth starts anyway.
Do it in StiqNote
On Pro and Agency, pinning a comment on the broken thing fills in most of this template automatically: the exact element, the browser and OS, screen size, console errors and failed network requests, and a replay of the last few minutes so the developer can see what led up to it. You still write what happened and what you expected; StiqNote brings the rest. Send it to GitHub, Linear, Jira or Asana with one click, and the thread's status stays in sync with the issue.
See bug reports with replay and logs for what comes with every report.
Stop sending screenshots in Slack
Pin the feedback where it belongs. Free to start, with 14 days of Agency for your first team.