Regression Detection

Automatically detect when resolved errors reappear in new releases and get notified immediately.

What Is Regression Detection?#

Regression detection identifies when a previously resolved error group starts occurring again in a new release. Instead of silently accumulating events on a "resolved" issue, JustAnalytics automatically reopens the error group, notifies your team, and tracks the regression count.

This closes a critical feedback loop: you fix a bug, deploy, and if the bug comes back (or the fix didn't work), you know immediately.

How It Works#

The regression detection system watches for a specific sequence of events:

1. Error group created          → status: UNRESOLVED
2. Team investigates and fixes  → status: RESOLVED (resolvedInRelease: v2.3.0)
3. New release deployed         → v2.4.0 tracked
4. Same error fingerprint seen  → from release v2.4.0
5. REGRESSION DETECTED          → status: REGRESSED, regressionCount: 1

Detection Logic#

When a new event arrives for a resolved error group, the system checks:

Is the error group resolved? If not, it's just another occurrence -- no regression.
Is the event from a different release? Compare the event's release version with resolvedInRelease. If they're the same release, it's a late-arriving event, not a regression.
Is the new release newer? Using semantic versioning or deployment timestamps, confirm the event comes from a release that was deployed after the resolution.

If all three conditions are true, a regression is declared.

What Happens on Regression#

When a regression is detected:

Status changes -- the error group moves from resolved to regressed
Regression count increments -- tracks how many times this error has regressed
Notification sent -- the assigned team member (or owner) is notified
Timeline entry added -- the regression event appears in the error group's timeline
Workflow triggers -- any workflows listening for error_regression fire

Release Tracking#

Regression detection depends on accurate release tracking. JustAnalytics needs to know which release each error event belongs to.

Setting the Release in the SDK#

import JA from '@justanalyticsapp/node';

JA.init({
  siteId: 'YOUR_SITE_ID',
  apiKey: 'YOUR_API_KEY',
  serviceName: 'api-server',
  release: 'v2.4.0',         // Set the current release version
});

Or use an environment variable:

JA_RELEASE=v2.4.0

Setting the Release in the Tracking Script#

For frontend errors tracked by monitor.js:

<script
  src="https://cdn.justanalytics.app/monitor.js"
  data-site-id="YOUR_SITE_ID"
  data-release="v2.4.0">
</script>

Release via Deploy API#

Notify JustAnalytics of new releases via the API:

await fetch('/api/ingest/releases', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': 'YOUR_API_KEY',
  },
  body: JSON.stringify({
    version: 'v2.4.0',
    service: 'api-server',
    environment: 'production',
    commitSha: 'abc123def456',
    commitMessage: 'Fix payment race condition',
    deployedAt: new Date().toISOString(),
  }),
});

resolvedInRelease Tracking#

When you resolve an error group, JustAnalytics records which release it was resolved in. This is the baseline used for regression comparison.

Automatic Resolution#

If you resolve an error group while a release is active, resolvedInRelease is set to the current active release for the affected service.

Manual Resolution#

When resolving from the dashboard, you can specify the release:

Open the error group
Click Resolve
Optionally select Resolve in release and choose the release version
Click Confirm

API Resolution#

await fetch(`/api/dashboard/error-groups/${groupId}`, {
  method: 'PATCH',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    status: 'resolved',
    resolvedInRelease: 'v2.3.0',
  }),
});

If resolvedInRelease is not specified, the system uses the latest known release for the error group's service.

Regression Notifications#

When a regression is detected, notifications are sent through your configured channels.

Default Notification#

The default notification includes:

Error group title and ID
The release it was resolved in
The release where it regressed
Number of new occurrences
Link to the error group

🔄 Regression Detected

Error: "Cannot read property 'id' of undefined"
Group: #ERR-1234
Resolved in: v2.3.0
Regressed in: v2.4.0
New occurrences: 12

View: https://app.justanalytics.app/dashboard/errors/ERR-1234

Notification Channels#

Regression notifications use the same channels as your alert notifications:

Email -- sent to the assigned owner or team
Slack -- posted to the configured channel
Webhook -- sent to your custom endpoint
In-app -- notification bell in the JustAnalytics dashboard

Configuring Regression Notifications#

Navigate to Dashboard > Settings > Notifications > Error Regressions:

Regression Notifications:
  ✅ Email assigned owner
  ✅ Slack #error-regressions
  ✅ Webhook: https://api.company.com/hooks/ja-regressions
  ☐  PagerDuty (disabled -- regressions are not pages)

Regression Count#

Each error group tracks how many times it has regressed. This is a signal of underlying instability.

What the Count Tells You#

| Regression Count | Interpretation | |-----------------|----------------| | 0 | No regressions -- stable fix | | 1 | One regression -- possibly an incomplete fix or a new variant | | 2-3 | Recurring issue -- the root cause hasn't been fully addressed | | 4+ | Systemic problem -- needs architectural attention, not just a patch |

Viewing Regression Count#

The regression count appears:

On the error group detail page header
In the error group list (as a badge)
In the error group API response
In regression notification messages

Filtering by Regression Count#

In the Error Tracking list view, filter by:

Regression Count: >= 2

This surfaces chronic issues that keep coming back, helping you prioritize deep fixes over quick patches.

The Regression Workflow#

Here's the typical workflow when a regression is detected:

Step 1: Triage#

When you receive a regression notification:

Open the error group
Check the new occurrences since the regression -- is it a trickle or a flood?
Check the regressed-in release -- what changed in that deploy?
Compare the new stack traces with the original -- same root cause or a new variant?

Step 2: Investigate#

The regression may indicate:

Incomplete fix -- the original fix didn't cover all code paths
Revert -- the fix was accidentally reverted or overwritten
New variant -- a similar but different bug in new code
Dependency change -- a library update reintroduced the issue

Look at:

The git diff for the regressed-in release
The original fix commit
The new stack traces compared to the original

Step 3: Fix#

Apply the fix and include the regression context in your commit message:

Fix regression: null check in payment handler

This error was resolved in v2.3.0 but regressed in v2.4.0 because
the refactor of the payment module didn't include the null check
from the original fix (commit abc123).

Fixes: ERR-1234
Regression-of: v2.3.0 fix

Step 4: Deploy and Verify#

Deploy the fix in a new release (e.g., v2.4.1)
Monitor the error group for new occurrences
Once confirmed stable, resolve the error group again with resolvedInRelease: v2.4.1

Step 5: Prevent#

If this error has regressed multiple times, consider:

Adding a regression test that specifically covers this case
Adding a code comment explaining why the fix is necessary
Reviewing the code review process for the affected area

Regression in the Dashboard#

Error Group Detail#

The error group detail page shows regression history:

Status: REGRESSED (was resolved in v2.3.0, regressed in v2.4.0)
Regression Count: 2

Regression History:
  2026-03-15  Resolved in v2.3.0 by @alice
  2026-03-20  Regressed in v2.4.0 (15 new occurrences)
  2026-03-21  Resolved in v2.4.1 by @alice
  2026-03-28  Regressed in v2.5.0 (3 new occurrences)

Regression Timeline#

On the error group's timeline view, regression events are highlighted with a distinct icon. Each regression entry shows:

The release that caused the regression
How many new occurrences followed
The time between resolution and regression

Regression Analytics#

Navigate to Dashboard > Error Tracking > Analytics for aggregate regression metrics:

Regression rate -- percentage of resolved errors that regress
Mean time to regress -- average time between resolution and regression
Top regressing errors -- errors with the highest regression counts
Regression by service -- which services have the most regressions

API Reference#

Get Error Group with Regression Info#

const response = await fetch(`/api/dashboard/error-groups/${groupId}`);
const group = await response.json();

// {
//   id: 'err_abc123',
//   title: "Cannot read property 'id' of undefined",
//   status: 'regressed',
//   resolvedInRelease: 'v2.3.0',
//   regressedInRelease: 'v2.4.0',
//   regressionCount: 2,
//   firstSeen: '2026-03-01T10:00:00Z',
//   lastSeen: '2026-03-28T14:22:00Z',
//   occurrenceCount: 1547,
// }

List Regressed Error Groups#

const response = await fetch('/api/dashboard/error-groups?status=regressed');
const data = await response.json();
// Returns all error groups with status 'regressed'

Resolve After Regression#

await fetch(`/api/dashboard/error-groups/${groupId}`, {
  method: 'PATCH',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    status: 'resolved',
    resolvedInRelease: 'v2.4.1',
  }),
});

Reopen the error group
Assign it to the original fixer
Post in Slack with the regression details
Create a ticket in your issue tracker

See Workflow Automation for configuration details.