bugpot

Field notes

How to write a bug report a developer can actually use

6 min readThe Bugpot team

A bug report is a handoff. Someone saw the thing break; someone else has to fix it. Everything between those two people is friction, and friction eats hours. The tickets developers reach for first are boring for the same reason: they answer the questions the developer would have asked anyway, before anyone has to ask them.

What a useful bug report actually contains

Strip a good ticket to its bones and it is always four things. The exact page. What the reporter did. What they expected. What actually happened. That is it. Every other field on the form is either a shortcut to one of those four things or noise.

The version we all know does not deliver those four things. It arrives as an email that says "the button looks weird on my screen." The reporter is not being lazy — they are describing what they saw, from their vantage point, with the vocabulary they have. It is the wrong medium for the message.

Fix the medium, not the reporter

The temptation is to publish a bug-report template, put it in the client onboarding pack, and hope. It never works. People report bugs in the same moment they are frustrated by them; asking them to fill in nine fields is asking them to swallow their frustration and then process it. They will not.

The move is to make the tool collect the four things automatically. A screenshot of the page state answers "the exact page." Environment capture — browser, operating system, viewport, URL — answers "which screen?" A console-error log answers "what actually happened." The reporter is only on the hook for what they expected, which is the sentence they were going to write anyway.

A shape you can steal

If you are still writing tickets by hand, use this shape and thank us later.

Title: Pay button clipped below 400px viewport

Expected: The Pay button is visible and tappable at all mobile widths.
Actual: On iOS Safari at 390 × 844 the button is cut off at the bottom.

Steps:
1. Open /checkout on iPhone 14 (Safari 18)
2. Complete the address form
3. Scroll to the payment section

Environment: Safari 18.2 / iOS 18 / 390 × 844 / DPR 3
Console: TypeError: btn.rect is undefined (checkout.js:214)
The best bug report is the one the developer can reproduce without asking a single follow-up question.

The rest is triage

Every report that lands with those four things can be triaged in under a minute. Priority is a function of impact and effort; assignment is a function of who owns the surface. Neither of those decisions is hard when the report itself is not the bottleneck. When it is, the whole queue slows down, and that is what most teams call "our bug backlog is out of control." It is not the backlog — it is the intake.

Keep reading

More field notes

4 min read

Shipping faster with two-way issue sync

One-way webhooks look tidy on the marketing page and cause quiet chaos in the inbox. Here is what a two-way sync actually needs to do.

Try the tool the post is about

Free for five websites. Install in two minutes.