Why Does My Error Tool Report Old Bugs as New After Every Deploy?
Error tools group errors by a signature, usually built from the message and stack trace. A new JavaScript bundle changes file names, line numbers and function names, so the same bug gets a new signature and appears as new. Source maps, stable grouping rules and release markers keep known bugs from resurfacing as new ones.
If every deploy floods your error list with issues your team already triaged, the cause is almost always how errors are grouped, not a wave of new bugs. This guide explains why it happens and how to keep your triage queue honest.
- Errors are grouped by a signature, and a new bundle can change it.
- The same bug then shows up as new and gets triaged again.
- Source maps, stable grouping and release markers prevent the duplicates.
- Compare error rates by release to spot true regressions.
Why does a new deploy create new-looking errors?
Most error tools build a signature from the error message, the stack trace and the code location. Modern builds minify and bundle JavaScript, so file names often include a content hash, and line and column numbers shift whenever any code changes. After a deploy, the same bug has a different file name and position, so the tool treats it as a brand-new error.
What does the duplicate cycle look like?
The sequence below repeats on every release, which is why triage queues fill with issues your team has already seen.
How do you stop duplicates from flooding triage?
- Upload source maps for every build. Grouping on original source locations instead of bundled ones keeps signatures stable.
- Tag each release. Release markers let you see which deploy introduced or resolved an issue.
- Review known issues first. Mark triaged issues and check new alerts against them before opening tickets.
- Filter third-party noise. Group or mute errors from scripts you do not control so they do not mask your own regressions.
How do you tell a regression from a relabeled old bug?
Compare, release by release, how many sessions each issue affects. A true regression appears or grows right after a specific release. A relabeled old bug has a familiar message and code path and a similar session count to an issue from before the deploy. Impact matters most: rank issues by the sessions and revenue they touch rather than by how many times they appear in the list. Noibu research reports that over 90% of website errors are never reported, so impact-based ranking surfaces problems your shoppers never mention. For a related example, see how a Shopify app can break checkout.
The short version
- New builds change error signatures, so old bugs look new.
- Source maps and release markers keep grouping stable.
- Rank issues by sessions and revenue affected, not by list count.
- Compare error rates by release to find true regressions.
How does Noibu fit?
Noibu's Bug Resolution agent finds and investigates errors that cost orders, ties them to sessions and revenue, and hands results back for your approval. Noibu lets you record releases so you can compare error activity across deploys. The agents work in the Noibu console and through Noibu MCP.
Noibu is AI for ecommerce operations, the always-on optimization system that keeps online stores running at their best. A team of supervised AI agents finds what's broken, slow, or leaking revenue, does the work, and hands results back for human approval. Trusted by retailers like Free People, Guess, Liquid I.V., and Ariat.
To see which errors are affecting your store right now, start with Noibu's free website audit.
Frequently asked questions
Why does the same bug show as new after a deploy?
What are source maps and why do they matter?
How do release markers help?
How can I tell a true regression from a duplicate?
Should I rank errors by count or by impact?
