How to write a great bug report
A practical template for bug reports engineers can actually act on, plus the eight fields that matter most.
A great bug report does one job: it lets a stranger reproduce the bug without asking you a follow-up question. That's it. Everything else is decoration.
The eight fields that matter
- What you tried to do (in one sentence).
- What you expected to happen.
- What actually happened.
- Steps to reproduce, numbered.
- Environment: browser, OS, viewport, locale.
- A screenshot or short clip.
- Console errors or network failures.
- Severity, in business terms (blocker, painful, polish).
The trap: confusing severity with priority
Severity is how badly the system is broken. Priority is when you'll fix it. A high-severity bug in a low-traffic feature can be a low-priority fix; a low-severity bug on the homepage is high-priority. Keep them separate fields.
Why automated capture wins
Tools like AnchorMark capture the screenshot, console, and environment for you so you can focus on the human-readable parts of the report. The eight fields above become two: what you tried to do, and what happened.
Template you can copy
When I tried to [action], I expected [result] but instead got [actual]. To reproduce: [numbered steps]. Severity: [blocker | painful | polish]. Captured context attached.