How long should a bug report be?

A tester files a ticket that says "Checkout is broken on staging." A developer replies four hours later: "Which browser? Which account? What did you click?" Two days pass before anyone writes a line of code.

The same week, another tester files 900 words about the same bug. The developer opens it, scrolls, sees a wall of text, and moves it to next sprint.

Both tickets failed. One was too short. One was too long. But length was not really the problem in either case.

Short version

Length is the wrong measure. Reproducibility on the first read is the right one.
A normal bug needs about 150 to 250 words of prose, plus evidence.
A typo needs one line. An intermittent bug needs more.
Never cut: title, environment, steps, expected vs actual, evidence, the error string, frequency.
Always cut: your theory, your apology, your priority opinion, and everything you tried.
Structure beats word count. A scannable 400-word ticket reads faster than a dense 150-word one.

The only test that matters

Here is my position: your bug report should be as short as it can be while still being reproducible on the first read.

That gives you a real test. Call it the one round trip test.

Can a developer who has never seen this feature open your ticket, follow it, and see the bug themselves, without sending you a single message?

If yes, your ticket is the right length. It does not matter if it is 40 words or 600.

If no, it is too short, no matter how many words it has. A 900-word ticket that never says which browser you used is a short ticket wearing a costume.

A practical rule of thumb

You still want a number to aim at.

Bug type	Rough length	What must be there
Typo or wrong label	One line	Where it is, what it says, what it should say
Visual bug	60-120 words	Screen size, browser, screenshot with the spot marked
Normal functional bug	150-250 words	Steps, environment, expected vs actual, error string, evidence
Intermittent or flaky bug	250-500 words	All of the above plus frequency, timing, and what changed between passes
Multi-system or data bug	300-600 words	All of the above plus the request or job ID and both sides of the boundary
Security bug	As long as needed	Full impact, exact reproduction, and who you told

Most of your tickets are the middle row. Around 200 words plus a screenshot, a console log, and a network capture handles most bugs a normal team files.

Failure mode one: the two-line ticket

This one is common, and it looks efficient.

Title: Checkout broken

Checkout is not working on staging. Please check.

Every question the developer now has to ask is a round trip. Each round trip is hours, sometimes a day.

Which browser and version?
Which account?
Which product, and what was in the cart?
What does "not working" mean? Blank page? Error? Wrong total?
Does it happen every time?

Five questions. Five delays. The ticket was two lines long, but it cost more of everyone's time than a 300-word ticket would have.

Short is only a virtue when nothing needed is missing.

Failure mode two: the 900-word essay

This one looks careful, which makes it harder to call out.

The reporter writes three paragraphs of background, a paragraph about how they noticed it, a paragraph guessing at the cause, then the reproduction steps buried in paragraph six, then an apology for the long message.

Developers do not read tickets like a novel. They scan for the steps, the environment, and the error. If those are buried in prose, the scan fails and the ticket goes back in the queue.

Long tickets are often slower to fix for a simple reason: the important line becomes invisible. If you write 900 words and one of them is TypeError: Cannot read properties of undefined (reading 'total'), that line is now hidden in a haystack you built yourself.

What to never cut

These seven things stay, even in your shortest ticket.

A specific title. "Order total shows 0.00 on Checkout when a discount code is applied" beats "Checkout broken."
Environment. Browser and version, OS, device, and which environment. For example: Chrome 130, macOS 15, https://staging.example.com.
Exact steps. Numbered. Starting from a known state, like a fresh login.
Expected vs actual. Two lines. This is the difference between a bug and a preference.
Evidence. Screenshot, video, console output, network request.
The error string, copied exactly. Developers search their code for that text.
Frequency. "Every time" and "3 out of 10 tries" send the developer down completely different paths.

That list fits in 150 words. That is the whole point.

What to cut

Your theory about the cause. Unless you read the code, it is a guess, and a wrong guess sends someone into the wrong file. If you have a strong hunch, put one line at the bottom under "Possible cause".
The apology. "Sorry if this is a duplicate, I know you're busy" adds nothing and pushes the steps further down.
Restating what the product does. The developer built it.
Screenshots of things that are not the bug. Three clean screenshots of working pages hide the one that matters.
The full history of what you tried. Nobody needs "I cleared cache, then tried incognito, then restarted, then tried my colleague's laptop." Keep only the results that narrow it down: "Also fails in incognito. Does not fail on Firefox 128."
Priority opinions you cannot support. "This is critical" means little on its own. "Blocks all card payments on live" means a lot.

Structure beats length

This is the part people get wrong when they hear "keep it short". A 400-word ticket with clear headings, numbered steps, and the error in a code block can be read in 30 seconds. A 150-word ticket written as one dense paragraph can take two minutes and still leave questions.

So do not compress by deleting facts. Compress by cutting words around the facts, and by putting each fact where a scanner expects to find it.

Worked example: cutting without losing anything

Before, 210 words of it wasted:

So I was going through the checkout flow this morning as part of regression, and I noticed something strange that might be related to the discount work that shipped last week, though I could be wrong. Basically, when I put a discount code in, the total goes weird. I tried a few things, cleared my cache, tried another browser, asked Priya and she saw it too I think. Sorry for the long message. This feels pretty critical. Might be a rounding thing in the pricing service?

After, 95 words, nothing lost:

Order total shows 0.00 on Checkout when discount code SAVE20 is applied

Environment: Chrome 130, macOS 15, https://staging.example.com, account [email protected]

Steps:

Add "Wireless Keyboard" ($49.99) to the cart.

Go to Checkout.

Enter discount code SAVE20 and click Apply.

Expected: Total shows $39.99. Actual: Total shows $0.00 and the Pay button stays disabled.

Frequency: Every time, 5 of 5 attempts. Also reproduced by Priya on Firefox 128.

Console: TypeError: Cannot read properties of undefined (reading 'discountedTotal')

Impact: Blocks all discounted checkouts on staging.

Shorter and far more useful. The theory went away. The apology went away. Two facts got added: the exact code, and the error string.

Worked example: expanding a ticket that is too short

Before:

Export doesn't work.

After, five lines added:

CSV export downloads an empty file when a date filter is set

Environment: Firefox 128, Windows 11, https://staging.example.com, account [email protected]

Steps: Reports > set range to 1-31 July 2026 > click Export CSV.

Expected: File with 412 rows. Actual: File with headers only, 0 rows.

Frequency: Every time with a date filter. Works fine with no filter.

That is about 60 words. It is enough. You do not need 400.

Some bug tools reduce this work for you. Crosscheck captures the screenshot, console logs, network requests, and environment details automatically when you report from the page, so the parts you type by hand are just the steps and the expected vs actual.

When longer is genuinely right

There are real cases where length earns its place.

Intermittent bugs. If it fails 3 times in 10, the developer needs your timing, your sequence, and what was different on the failing runs. That detail cannot be compressed.
Bugs crossing systems. A payment that succeeds in the gateway but fails in your database needs both sides, plus IDs to match them.
Security bugs. Write the full impact and the exact reproduction. The cost of being unclear is far higher than the cost of extra words.
Anything a future person will search. Some tickets become the permanent record of a tricky behaviour. Extra context there pays for itself for years.

The rule still holds in all four cases. They are longer because reproducing them honestly requires more, not because more words feel more thorough.

Frequently asked questions

Is there a word count I should aim for? About 150 to 250 words of prose for a normal functional bug, plus attachments. Treat it as a signal, not a limit. If you are far above it, check whether you are adding facts or padding.

Should I write less if the developer sits next to me? No. Write the ticket for the person who reads it in six months, not the person you can tap on the shoulder today.

What if I cannot reproduce it reliably? Say so clearly, and give the frequency and the conditions of the failing runs. "Fails about 3 in 10 on the second checkout attempt" is far more useful than leaving it out.

Do templates make tickets too long? Only when people feel they must fill every field. Leave a field empty rather than writing "N/A" five times, and trim fields your team never reads.

Should I split one long ticket into several? Yes, if it describes more than one bug. One ticket per bug keeps each one short, testable, and closable on its own.