Closing 1,000 stale bugs without losing the real ones

Your tracker says 1,412 open bugs. The oldest was filed in 2021, against a screen that no longer exists. Nobody has opened the list in eight months, and when a customer reports something, nobody checks whether it is already in there — because searching 1,412 tickets is slower than filing a new one.

That backlog is not a record of work. It is a filing cabinet in a locked room. But somewhere inside it are perhaps thirty bugs that are real, current, and worth fixing, and losing those is the risk that stops most teams from ever cleaning up.

Short version

A backlog nobody reads has zero value and real cost — it hides the bugs that matter.
Close in bulk by rule, not by reading every ticket. Reading 1,400 tickets never finishes.
Protect four categories from bulk closing: security, data loss, money, and anything a customer reported.
Give every closed ticket a rescue window — 30 days where reopening is one click.
Announce the rules before you run them, and let people rescue tickets in advance.
Then set an auto-close policy so the pile never comes back.

Why a stale backlog costs you

The instinct is that an ignored list is harmless. It is not.

It hides real bugs. The five current, serious bugs are indistinguishable from 1,400 old ones. Anything that makes searching slow means duplicates get filed instead of found.

It makes your numbers meaningless. "We have 1,412 open bugs" tells a stakeholder something alarming and false, since most of those are fixed, obsolete, or trivial. It also hides the trend: with a healthy 40-item backlog, a jump to 70 is a visible signal, but inside 1,400 a bad month is invisible.

It demoralises people. A number that only ever goes up teaches the team that bug work is pointless.

Old bugs also decay in a specific way: the code changed, the screen was redesigned, the reporter left, and the steps reference a UI that no longer exists. Most are not fixable even if you wanted to fix them.

Step 1: measure before you touch anything

Twenty minutes with your tracker's filters. You need four numbers.

Total open bugs.
Distribution by age — under 30 days, 30 to 90, 90 to 365, over a year.
Distribution by severity, within each age band.
How many have any activity in the last 90 days — a comment, a status change, an assignment.

The typical shape: 70 to 85% of the backlog is over a year old with no activity, and almost all of it is Minor or Trivial. That is the part you can close by rule. The remaining 15 to 30% is where you spend your reading time.

Write these numbers down. They are your before-and-after evidence, and you will need them when someone asks whether the cleanup was worth it.

Step 2: protect the categories you must not bulk-close

Decide this before writing any rules. These four are exempt from every automatic rule, regardless of age.

Security. Anything about authentication, permissions, data exposure, or injection. Age does not fix a security bug.
Data loss or corruption. Anything where a user could lose work or see wrong data saved.
Money. Billing, pricing, invoices, refunds, tax. A four-year-old billing bug may still be charging someone incorrectly.
Customer-reported. Anything filed on behalf of a named customer. Closing these silently is how you get the same issue escalated through support next quarter, with an unhappy account attached.

Add a fifth if it applies to you: regulatory or accessibility findings with a compliance obligation. Those need a documented resolution path rather than a close.

Tag these first with a query, before you run anything else. If your tracker cannot find them by field, search titles and descriptions for terms like password, permission, invoice, refund, data loss, GDPR, WCAG.

Step 3: bulk triage rules

Now the rules. Each one should be a saved filter you can run and count before you execute it.

Rule	Condition	Action
Obsolete area	Relates to a feature or screen that no longer exists	Close as `obsolete`
Ancient and trivial	Severity Minor or Trivial, no activity in 365+ days	Close as `stale`
Old and unassigned	Severity Major, no activity in 540+ days, never assigned	Close as `stale`
Unreproducible and cold	Status is "cannot reproduce" or "needs info", no reporter reply in 60+ days	Close as `insufficient information`
Duplicates	Same component and a very similar title	Link and close as `duplicate`
Reporter gone	Reporter left the company, severity Minor or below, no activity in 180 days	Close as `stale`
Everything else	Anything not matched above	Read individually

Two things make this safe.

Run each rule as a preview first. Get the count. If "ancient and trivial" matches 890 tickets, spot-check twenty of them at random before executing. If more than one or two of your twenty look like they should survive, the rule is too broad — tighten it and re-check.

Close in batches by rule, not all at once. One rule per day makes it obvious which rule caused a problem if someone objects.

After the rules run, the "read individually" pile is usually 100 to 250 tickets. That is one focused afternoon with a developer and a product owner, at roughly 60 seconds each, deciding fix / keep / close.

Step 4: the rescue window

This is the mechanism that makes bulk closing acceptable rather than reckless.

Every bulk-closed ticket gets:

A resolution of stale or obsolete, never won't fix. The distinction matters — won't fix claims a judgement was made about the bug, and none was.
A standard comment explaining what happened and how to undo it.
A label such as bulk-closed-2026-06, so every ticket from this cleanup can be found in one query afterwards.
A 30-day rescue window where reopening requires no justification at all.

The comment should be short and honest.

Closed as part of a backlog cleanup on 27 June 2026. This ticket had no activity for over a year and was rated Minor. No judgement was made about whether the bug still exists. If it does, reopen it — no explanation needed — and it will be triaged normally. Reopening is welcome for 30 days and after.

What matters is the tone. "Closed — stale" with no comment reads as the tracker being tidied at the expense of people's work. The paragraph above reads as a decision with a door left open.

Do not notify every reporter individually by email. A thousand automated emails is how a reasonable cleanup becomes a company-wide argument. Announce it once, in the team channel, before you start.

Step 5: keep the team's trust

The cleanup is technically easy. The trust part is where these go wrong.

Announce a week ahead. Post the rules, the counts each rule will match, the date, and the rescue window. One short message.
Offer a rescue list in advance. "If there are tickets you care about, add the label keep before Friday and they will be skipped." Very few people use it, and offering it changes how the cleanup is received entirely.
Name a person, not a script. Someone owns the cleanup and answers questions about it. An automated mass close with no human attached feels like something being done to the team.
Publish the before-and-after. "1,412 open, now 137. 890 closed as stale, 210 as obsolete, 133 as duplicates, 42 kept and prioritised." The last number is the important one — it shows the point was finding real bugs, not deleting tickets.
Fix something from the kept pile immediately. Nothing proves the exercise was honest like three of the rescued bugs being fixed the following sprint.
Never close bugs from a single person or team in bulk. Rules must be about age and severity, never about who filed it.

Step 6: stop it coming back

A one-time cleanup without a policy means the same conversation in eighteen months. Add three rules the day you finish.

An auto-close policy. Any bug with no activity for 180 days, at severity Minor or below, and not in a protected category, is closed automatically as stale. Post a comment 14 days before, so anyone watching can object with one click. Most trackers can do this with a scheduled rule or an automation.

A backlog cap. Set a number — 50 open bugs is realistic for a team of ten. If the count goes above it, the next triage session is a cleanup session rather than a planning one. A cap turns an abstract problem into a visible one.

Triage within 48 hours. Every new bug gets a decision inside two days: fix now, schedule with a date, or close with a reason. Bugs become stale because they were never decided on, not because they were decided against.

There is a quieter contributor too. A large share of old tickets are unfixable not because they are old, but because they were thin when they were filed — no environment, no console output, no reproduction path, and now nobody can tell whether they are still real. Reports that arrive complete, with the screenshot, console errors, network requests, and environment captured at the moment of reporting, age far better than a two-line description. That is the underlying job of tools such as Crosscheck, and it is the difference between a two-year-old ticket you can still evaluate and one you can only guess about.

What to expect afterwards

Expect around 2 to 5% of bulk-closed tickets to be reopened within the rescue window. That is the correct number. Zero reopens means people are not looking. Above about 10% means your rules were too aggressive, and you should check which rule caused it.

Expect the remaining backlog to actually get read, because a 137-item list is readable and a 1,412-item list is not. That is the whole return: not a smaller number, but a list someone opens.

Frequently asked questions

Is it safe to close bugs we never investigated? Yes, if they are old, low severity, outside the protected categories, and reopening is easy. A bug sitting unread for two years is already effectively closed — the cleanup just makes that honest and searchable.

Should we delete stale bugs instead of closing them? No. Never delete. Closed tickets stay searchable, which is what lets you find prior context when the same issue is reported again.

What if a manager objects to closing bugs they filed? Show the rules and the rescue window, and offer to skip anything they label keep before the cleanup runs. The offer resolves nearly every objection, because the concern is usually about being overruled, not about the tickets.

How often should we do a cleanup like this? Ideally once, then never again. With an auto-close policy, a backlog cap, and 48-hour triage in place, the pile does not rebuild. If you find yourself needing a second cleanup, the policy is not being enforced.

What is a healthy open bug count? Roughly two to five open bugs per engineer, as a rough guide. A team of ten sitting steady between 20 and 50 is normal. The direction matters more than the number — flat or falling is fine, steadily rising is not.