How long should a bug report title be?

Aim for roughly 8 to 12 words — long enough to name the area, symptom, and condition, short enough to scan in a backlog list. If you can't fit the essentials, the extra detail belongs in the body, not the title.

Should a bug title describe the cause or the symptom?

Describe the symptom you actually observed unless the root cause is confirmed. "Login returns 500 after password reset" is verifiable; "Session cookie bug" is a guess that misroutes the ticket if you're wrong.

Why does the bug title matter if all the detail is in the body?

The title is the only part read during triage, in backlog scans, in search, and in dedup. A vague title like "doesn't work" forces every reader to open the ticket to learn anything, which is the single most repeated cost across a backlog.

How to Write a Bug Report Title That Speeds Up Triage

A good bug report title states what breaks, where, and under what condition in one scannable line — for example, "Checkout: 'Place Order' button does nothing on Safari 17". The goal is to let a triager understand and route the bug without opening it, and to make the ticket findable later during search and deduplication. Everything else — steps, environment, evidence — belongs in the body.

What makes a good bug report title?

A strong title carries three pieces of information and nothing else:

The area — the feature, page, or component where it happens (Checkout, Login, Settings > Billing). Front-loading this is what makes a backlog scannable and lets you group related tickets at a glance.
The symptom — what you observed, in verifiable terms ("returns a 500", "button does nothing", "total shows £0.00"). Describe what happened, not what you assume caused it.
The condition — the specific browser, user role, plan, or state that triggers it. This is usually the detail that distinguishes a real bug from a duplicate or a false report.

If a reader can predict the ticket's priority and owner from the title alone, it's doing its job.

A simple formula for bug titles

When you're unsure how to phrase one, use this pattern:

[Area]: [what happens] [where/under what condition]

Worked through it looks like:

Billing: invoice PDF download returns 404 for annual-plan accounts
Search: pressing Enter reloads the page instead of submitting the query
Onboarding: "Continue" button is disabled after uploading an avatar on Firefox

Each one names the surface, states an observable symptom, and pins the condition. A developer can start reproducing before reading a single line of the description.

Bug title examples: before and after

The difference is almost always specificity. Watch what happens when you add the three pieces:

Before: "Login broken" → After: "Login: SSO redirect loops indefinitely for Google Workspace users"
Before: "Page looks weird" → After: "Dashboard: chart legend overlaps data on screens under 1280px"
Before: "Export doesn't work" → After: "Reports: CSV export includes deleted rows for admin role"

The "before" titles force every triager to open the ticket just to learn what area it touches. The "after" titles are triaged, routed, and searched in seconds.

Common bug title mistakes to avoid

Most weak titles fall into one of these traps:

Vague verbs. "Broken", "doesn't work", "issue with X", and "weird behavior" describe nothing. Replace them with the exact symptom you saw.
Guessing the cause. "Session cookie bug" is a hypothesis. If it's wrong, the ticket routes to the wrong team and wastes a triage cycle. State the symptom; save the theory for the body.
Burying the area. "Getting an error when I try to check out" hides "Checkout" mid-sentence. Lead with it.
Cramming the whole report in. A title with steps, versions, and expected results is unscannable. Keep it to a line; the body holds the rest.
Duplicate-blind titles. If your title could describe five different bugs, it will collide with them in search. Add the distinguishing condition (browser, role, plan) that makes it unique.

Do bug titles still matter with automated bug reporting?

Yes — arguably more, because the body increasingly writes itself. Modern in-app bug reporting tools capture the URL, console, network, and environment automatically, so the human's job narrows to the one thing a machine can't reliably infer: a clear, specific summary of what the person actually experienced. A precise title turns that rich, auto-captured evidence into a ticket a developer can act on immediately, and it's what makes the report findable when someone hits the same issue next month.

If you want the surrounding structure to match, pair this with our guides on writing a bug report developers act on and triaging a bug backlog.