12 bug report title formulas that get your ticket fixed first

A developer opens the bug list in the morning. There are 40 tickets. They will not read all of them. They will read the titles, pick three, and start work.

Your title decides if your bug is one of those three.

A good title answers three questions in one line: what broke, where it broke, and when it broke. That is the whole job. This guide gives you 12 formulas you can copy today.

Short version

Put the problem first, not the page name.
Say what you saw, not what you think the cause is.
Add the condition ("when...", "after...", "only on...").
Keep it under about 12 words.
Never write "not working", "broken", or "issue" alone.

Why the title matters more than you think

Most bug tools show only the title in the list view. The description, the screenshot, and the logs are all hidden until someone clicks.

So the title has two jobs:

Help people search. Six months later, someone will type "checkout" into the search box. Your title needs the word "checkout" in it.
Help people decide. A team lead reads 40 titles and sorts them. A clear title gets sorted into "fix now". A vague title gets sorted into "ask QA later".

"Ask QA later" is where bugs go to die.

The basic shape

Almost every strong bug title follows one simple shape:

[What broke] on [where] when [condition]

Here is that shape in action:

Save button does nothing on Edit Profile when the phone field is empty
Total shows 0.00 on Cart when a discount code is applied
App crashes on Android 14 when opening a PDF from email

You can see the bug in your head after reading each one. That is the goal.

The 12 formulas

1. The action that fails

[Element] does not [expected action] on [page]

Save button does not save changes on Settings page

Use this for the most common bug type: you clicked something and nothing happened.

2. The wrong value

[Field] shows [wrong value] instead of [correct value] on [page]

Order total shows $0.00 instead of $49.99 on Checkout

Always include both numbers. "Wrong total" makes the developer guess. "$0.00 instead of $49.99" does not.

3. The error message

"[Exact error text]" appears when [action]

"Something went wrong" appears when uploading a file over 5 MB

Copy the error text exactly, in quotes. Developers search their code for that string.

4. The crash

App crashes on [screen] when [action]

App crashes on Photo Gallery when scrolling fast

Crashes are the highest priority bug type. Say the word "crashes" early so it is visible in the list.

5. The condition-only bug

[Problem] only when [condition]

Login fails only when the password contains a space

The word "only" is powerful. It tells the developer this is a narrow case, and it tells them exactly where to look.

6. The browser or device bug

[Problem] on [browser/device] only

Dropdown menu is cut off on Safari iOS only

If a bug happens in one place and not another, that belongs in the title. It saves an hour of back-and-forth.

7. The visual bug

[Element] [visual problem] on [screen size or page]

Footer text overlaps the logo on screens under 400px

Say what the eye sees. Do not say "UI is ugly" or "styling issue".

8. The missing thing

[Thing] is missing from [place] after [action]

Uploaded photo is missing from the profile after page refresh

"Missing" is clearer than "not showing" because it suggests data loss, which raises priority correctly.

9. The slow thing

[Page or action] takes [time] to [finish]

Search results take 14 seconds to load with 500+ products

Always put a real number. "Slow" is an opinion. "14 seconds" is a bug.

10. The wrong permission

[Role] can [action they should not do]

Viewer role can delete comments on shared boards

This shape is used for security and permission bugs. It reads like a rule being broken, which is exactly what it is.

11. The data bug

[Data] is [wrong state] after [event]

Customer address is blank after importing from CSV

Data bugs often affect many users at once. Make the data object the first word.

12. The regression

[Feature] stopped working after [release or change]

Email notifications stopped working after release 4.2

The word "stopped" tells everyone this used to work. That usually means a recent change caused it, which makes it much faster to find.

Before and after

Real titles improve fast once you apply the shape.

Weak title	Strong title
Login issue	Login fails with "Invalid token" after 30 minutes idle
Bug in cart	Cart quantity resets to 1 when the browser back button is used
Page broken	Reports page shows a blank white screen on Firefox 128
Doesn't work	Export to CSV downloads an empty file when a date filter is set
Urgent!! fix asap	Payment fails for all Visa cards on the live site
Small UI thing	Error text is white on white in the sign-up form
Weird behaviour	Search returns deleted products when sorting by price

Notice that the "before" titles are all shorter. Short is not the goal. Clear is the goal.

Five words to remove from your titles

"Issue" — every ticket in the tool is an issue. It adds nothing.

"Not working" — this describes almost every bug ever filed. Say how it fails instead.

"Broken" — same problem. Broken how? Blank page? Error? Wrong number?

"Urgent" or "ASAP" — priority belongs in the priority field, not the title. Putting it in the title looks like pressure, and teams learn to ignore it.

"Sometimes" — if it is intermittent, that is important, but say the condition you suspect. "Sometimes fails" helps nobody. "Fails on the second attempt" helps a lot.

Do not put the cause in the title

This is a common mistake, and it is an easy one to make when you know the codebase.

Bad: Null pointer in the OrderService causes total to be zero

Unless you have read the code and confirmed it, you are guessing. If your guess is wrong, the developer wastes time in the wrong file, then closes the ticket as "cannot reproduce".

Good: Order total shows 0.00 on Checkout when a discount code is applied

Report what you observed. Let the developer diagnose. If you do have a strong theory, put it in the description under a heading like "Possible cause" — clearly marked as a guess.

A quick self-check

Before you file, read your title and ask:

Could someone find this in six months by searching one keyword from it?
Does it say what broke, not just where?
Does it include the condition that triggers it?
Would a developer who has never seen this feature understand it?
Is it free of "issue", "broken", and "not working"?

If you answer yes five times, file it.

Where the title fits in the whole report

A great title gets your bug opened. What keeps it moving is everything behind it: clear steps to reproduce, the exact environment, and real evidence like a screenshot, console errors, and network requests.

Tools like Crosscheck capture that evidence automatically when you report the bug from the page itself, so the title is the only part you still have to write by hand. That is a fair trade.

Frequently asked questions

How long should a bug report title be? Aim for 8 to 12 words. Long enough to include what, where, and when. Short enough to read in the list view without being cut off.

Should I add the ticket type, like [BUG] or [UI]? Only if your team already does it. Most modern bug trackers have a type field, so a prefix just uses up space.

Should the title include the environment? Include it only when the environment is part of the bug. "Safari only" belongs in the title. "Chrome 130 on Windows 11" belongs in the environment field.

What if I do not know what caused it? That is normal and completely fine. Describe what you saw. Diagnosis is the developer's job, not yours.

Is it okay to edit a title later? Yes, and you should. When you learn the real trigger, update the title. A ticket that stays accurate stays useful.