20 phrases to delete from every bug report

A developer picks up a ticket that says "Cart sometimes doesn't work, please fix ASAP." They open the cart page. It works. They close the ticket as "cannot reproduce."

Two days later a customer complains about the same thing. Now it is urgent for real, and nobody has any of the details from the first report.

The bug was real both times. The words were the problem.

Short version

• Write what you saw, with numbers. Do not write what you concluded.
• Replace "sometimes" with a count: 3 of 10 attempts.
• Replace "broken" with the exact error text and the exact URL.
• Never guess at the cause in the report. Guesses send people to the wrong file.
• Never estimate someone else's work ("small change", "easy fix").
• Priority words belong in the priority field, not in the description.

---

Phrases that hide the facts

These sound like information. They carry none. Each one makes the developer ask a follow-up question, and every follow-up costs a day.

1. "Sometimes"

This tells the developer the bug is hard to reproduce, but not how hard. They cannot tell if they should try twice or twenty times.

Replace with: Fails on 3 of 10 attempts on Chrome 126, Windows 11.

2. "Randomly"

Almost nothing in software is random. There is a trigger you have not found yet. Saying "randomly" stops the search.

Replace with: Fails on the second checkout in the same session. First checkout always works.

3. "For some reason"

This is filler. It adds words and removes trust, because it suggests you did not look.

Replace with: After clicking Save, the console shows TypeError: Cannot read properties of undefined (reading 'total').

4. "Nothing happens"

Something always happens. The page stays still, but a request fires, or an error lands in the console. The console is the developer tools panel where the browser prints errors.

Replace with: The Save button returns 500 Internal Server Error from POST https://api.staging.example.com/v1/orders. No message shows on screen.

5. "The usual place"

You know the usual place. The developer who joined last month does not. Neither does the person reading this ticket in eight months.

Replace with: On https://staging.example.com/cart, in the order summary panel on the right.

6. "Same as before"

Tickets get split, merged, and archived. "Before" points at nothing a search engine can find.

Replace with: Same failure as CC-482, but now on the cart page instead of checkout. Steps repeated below in full.

---

Phrases that guess at the cause

You may be right. But if you are wrong, the developer spends hours in the wrong file, then closes the ticket. Report the symptom. Let them diagnose.

7. "I think the API is wrong"

An API is the server endpoint your app calls for data. Your theory may be correct, but stating it as the headline hides what you actually saw.

Replace with: POST https://api.staging.example.com/v1/orders returns 500 Internal Server Error. Response body: {"error":"order_total_null"}.

8. "The page crashed"

A crash means the process died. A blank page, a frozen tab, and a red error box are three different bugs with three different causes.

Replace with: The tab froze for 30 seconds, then Chrome showed the "Aw, Snap" page. Repeated 2 of 3 times.

9. "The site is down"

Down means nobody can reach it. Most of the time one page is failing for one account, which is a very different fix.

Replace with: https://staging.example.com/cart returns a blank white page for [email protected]. The home page and login both load normally.

10. "On my machine it fails"

Machines have names, versions, and settings. Without them, the developer cannot copy your setup.

Replace with: Fails on Chrome 126, Windows 11, screen 1920x1080, no extensions. Passes on Firefox 128, same machine.

11. "It should be easy to fix"

You do not know the code behind the button. This line adds pressure and nothing else. It also reads as a promise the developer never made.

Replace with: nothing. Delete the sentence and add impact instead: Blocks 40 users from checking out, no workaround.

12. "It's a small change"

Same problem as the last one, and it is often worse. A one-pixel visual fix can touch a shared component used on 30 screens.

Replace with: Requested change: the error text under the email field should be red (#D92D20), not grey. Screenshot attached.

---

Phrases that judge instead of describe

These are opinions wearing the clothes of a bug report. An opinion cannot be reproduced, so it cannot be fixed or verified.

13. "It's broken"

Broken how? Blank screen, wrong number, error message, and slow load all get called broken.

Replace with: Order total shows $0.00 instead of $49.99 on https://staging.example.com/cart when a discount code is applied.

14. "Doesn't work"

This describes roughly every bug ever filed. It is the single most common line in bad tickets, and it forces a reply asking what you actually saw.

Replace with: Clicking Apply on the promo code field does nothing visible. Console shows TypeError: Cannot read properties of undefined (reading 'total').

15. "Not user friendly"

That is a design opinion, and design opinions belong in a design ticket. Even then, name the exact problem.

Replace with: The Continue button is below the fold on a 1366x768 screen. 6 of 8 testers scrolled past it and clicked Back instead.

16. "Just"

"Just add a check", "just change the label". The word makes real work sound trivial, and it quietly hides the parts you have not thought about.

Replace with: Expected: the form blocks submit and shows "Enter a valid email" when the email field is empty.

---

Phrases that push instead of inform

Pressure words do not raise priority. Teams learn to ignore them fast, which means the one genuinely critical ticket gets ignored too.

17. "Urgent" with no reason

Every reporter thinks their bug is urgent. A number is what actually moves a ticket up the list.

Replace with: Blocks 40 users from checking out, no workaround. Revenue impact roughly $2,000 per day.

18. "Please fix ASAP"

ASAP is not a date and not a priority level. It only tells the developer you are worried.

Replace with: Needed before the release on 2026-08-04. Marked P1 in the priority field.

19. "Obviously"

If it were obvious, you would not be writing the ticket. This word makes the reader feel slow, and it usually replaces the detail they needed.

Replace with: Expected the cart to keep 3 items after refresh. It shows 1 item.

20. "As you know"

Often the reader does not know. Even if they do, this line lets you skip context that the ticket needs to stand on its own in six months.

Replace with: Context: the discount service was switched to v2 in release 4.2 on 2026-07-22.

---

The worst offenders at a glance

Keep this table near you while you write. These six show up in most weak reports.

Notice that every replacement is longer. Length is not the point. Every replacement can be checked by someone else, and that is the point.

---

The one rule behind all 20

Write what you observed, with numbers. Do not write what you concluded.

That is the whole rule. "Sometimes" is a conclusion about frequency; "3 of 10 attempts" is an observation. "The API is wrong" is a conclusion about cause; a 500 response body is an observation. "Urgent" is a conclusion about priority; "blocks 40 users" is an observation.

Observations can be reproduced, argued with, and closed. Conclusions can only be believed or ignored.

The catch is that observations take effort to collect: the browser version, the console error, the failed request, the exact URL. That is where most reporters give up and fall back to "it's broken". Tools like Crosscheck capture the screenshot, console logs, network requests, and environment details automatically when you file the bug from the page, so the facts are already attached and you only write the part a human has to write.

---

Frequently asked questions

What if I truly do not know how often the bug happens? Say what you did measure. "Seen twice in one hour of testing, not reproduced in 5 deliberate attempts" is honest and far more useful than "sometimes".

Is it ever fine to suggest a cause? Yes, in its own labelled line at the bottom, such as "Possible cause: the discount service v2 switch in release 4.2". Keep it out of the title and out of the summary.

Our team uses "ASAP" all the time. Should I push back? Use the priority field and add a real deadline or a user count. Once a few tickets carry numbers, the pressure words tend to fade on their own.

How do I report a design problem without saying "not user friendly"? Describe the behaviour and the cost. "6 of 8 testers clicked Back instead of Continue" is a bug report. "Not user friendly" is a review.

Does this make bug reports too long? A little longer, yes. Aim for a screen of text. You are trading two minutes of your writing time for a day of someone else's guessing time.