Advanced Issue Management: Merging, Regression Detection, and Ownership

Beyond "Error Happened"

Capturing errors is the easy part. Every monitoring tool does that. The hard part is managing the lifecycle of thousands of errors across a growing codebase: grouping duplicates, detecting regressions, assigning ownership, and connecting errors to the engineering workflows that fix them.

Sentry set the standard for issue management in error tracking. We've studied what they do well, listened to what teams wish worked better, and built an issue management system in JustAnalytics that handles the full lifecycle from first occurrence to permanent resolution.

Issue Merging and Unmerging

The Duplicate Problem

Error grouping algorithms aren't perfect. Sometimes the same underlying bug produces slightly different stack traces -- different minification outputs, different browser error messages, or different code paths that all lead to the same root cause. You end up with five issues in your dashboard that are really one issue.

Merging Issues

Select two or more issues and merge them into a single issue:

Before merge:
  Issue #1042: TypeError: Cannot read property 'map' of undefined (342 events)
  Issue #1051: TypeError: Cannot read properties of undefined (reading 'map') (189 events)
  Issue #1067: Uncaught TypeError: x.map is not a function (56 events)

After merge:
  Issue #1042: TypeError: Cannot read property 'map' of undefined (587 events)
  Merged from: #1051, #1067

When you merge issues:

Event counts are combined -- you see the true frequency of the underlying bug
All stack traces are preserved -- you can still inspect individual events
Assignees are preserved -- the primary issue's assignee is kept
Comments are combined -- conversation history from all issues is merged chronologically
Alerts consolidate -- future events matching any of the merged fingerprints route to the single issue

Unmerging Issues

Merged the wrong issues? Unmerge them:

Issue #1042 (587 events)
  → Unmerge
  → Select events to split out
  → New issue #1089 created with 56 events (the x.map ones)

Unmerging creates a new issue with the events you selected. The original issue retains everything else.

Merge Suggestions

JustAnalytics analyzes your issue list and suggests merges when it detects likely duplicates:

Suggested Merges:

"TypeError: Cannot read property 'name' of null" (#1080, 120 events)
"TypeError: Cannot read properties of null (reading 'name')" (#1095, 87 events)
Confidence: 94% -- Same stack trace, different error message format

"NetworkError: Failed to fetch" (#1012, 2,400 events)
"TypeError: NetworkError when attempting to fetch resource" (#1018, 890 events)
Confidence: 88% -- Same origin, different browser error messages

Review and approve merges with a single click, or dismiss suggestions you disagree with. The model learns from your decisions and improves its suggestions over time.

AI-Powered Similar Issue Detection

Beyond exact duplicates, JustAnalytics uses embeddings to find semantically similar issues -- errors that are related but not identical.

How It Works

When a new issue is created, JustAnalytics:

Generates an embedding from the error message, stack trace, and context
Searches for existing issues with similar embeddings
Ranks matches by similarity score
Displays similar issues on the issue detail page

Similar Issues Panel

Issue #1102: PaymentProcessingError: Card declined

Similar Issues:
  87% match -- #1045: PaymentProcessingError: Insufficient funds (resolved)
  82% match -- #1078: PaymentProcessingError: Card expired (open)
  74% match -- #989: StripeError: Your card was declined (resolved)
  68% match -- #1034: PaymentProcessingError: Invalid card number (open)

This helps in several ways:

Find related fixes -- if a similar issue was already resolved, the fix might apply here too
Identify patterns -- multiple similar payment errors might indicate a systemic problem with your payment integration
Avoid duplicate work -- before investigating a new issue, check if a teammate already solved a similar one

Contextual Similarity

JustAnalytics considers more than just the error message:

Stack trace similarity -- errors with similar call stacks, even with different messages
URL patterns -- errors occurring on the same page or API endpoint
User context -- errors affecting similar user segments
Temporal proximity -- errors that started occurring around the same time

Auto-Regression Detection

What's a Regression?

A regression occurs when a previously resolved error starts happening again. This typically means a bug fix was incomplete, reverted, or reintroduced in new code.

How Detection Works

When you mark an issue as Resolved, JustAnalytics monitors for new events matching that issue's fingerprint. If new events arrive, the issue is automatically reopened with a Regression label:

Issue #1045: PaymentProcessingError: Insufficient funds
Status: Regression (was Resolved on March 20)

Regression detected: March 28, 2026 at 14:22 UTC
New events since regression: 47
Likely trigger: Deploy v2.4.1 at 14:15 UTC

Previous resolution:
  Resolved by: Sarah Chen on March 20
  Fix commit: abc123 "Handle insufficient funds gracefully"
  
Current regression:
  First event: March 28, 14:22 UTC
  Affected version: v2.4.1
  Stack trace: [differs from original -- new code path]

Regression Alerts

Regressions trigger a dedicated alert that includes:

Original resolution details -- who fixed it and when
The deploy that likely caused the regression -- matched by timestamp
Stack trace comparison -- what changed between the original error and the regression
Affected user count -- how many users are impacted

Resolve with Version

When resolving an issue, you can specify "Resolved in version X." JustAnalytics will only flag a regression if the error occurs in version X or later:

Resolve Issue #1045
  ○ Resolve now
  ● Resolve in next release
  ○ Resolve in version: [v2.5.0]

This prevents false regressions when old versions of your app are still running in the wild while the fix is deployed to newer versions.

CODEOWNERS and Ownership Rules

The Ownership Problem

In large teams, nobody owns an error until someone assigns it. And assignment often happens hours or days after the error starts occurring, because everyone assumes someone else will handle it.

CODEOWNERS Integration

JustAnalytics reads your repository's CODEOWNERS file (or .github/CODEOWNERS) and automatically assigns issues to the team that owns the affected code:

# .github/CODEOWNERS
/src/payments/        @backend-payments
/src/auth/            @backend-auth
/src/components/ui/   @frontend-ui
/src/api/             @backend-api
/packages/sdk/        @sdk-team

When an error occurs in /src/payments/stripe.ts, the issue is automatically assigned to @backend-payments.

Custom Ownership Rules

For more granular control, define ownership rules in JustAnalytics that override or extend CODEOWNERS:

Ownership Rules:

  - name: "Payment errors"
    match:
      error_type: "PaymentProcessingError"
    owner: backend-payments
    priority: P1

  - name: "Checkout page errors"
    match:
      url: "/checkout/*"
    owner: frontend-checkout
    priority: P2

  - name: "API 5xx errors"
    match:
      tag: "http.status_code:5*"
      service: "api-gateway"
    owner: backend-platform
    priority: P1

  - name: "Mobile browser errors"
    match:
      browser: ["Mobile Safari", "Chrome Mobile"]
      error_type: "TypeError"
    owner: frontend-mobile
    priority: P3

Ownership Routing

When a new issue is created, JustAnalytics evaluates ownership rules in priority order:

Check custom ownership rules (most specific match wins)
Check CODEOWNERS based on the error's stack trace file paths
Fall back to the site's default owner

The assigned team receives the issue notification immediately, eliminating the delay between detection and assignment.

Ownership Dashboard

Track ownership distribution and response times by team:

Issue Ownership - March 2026

Team              | Open | Resolved | Avg Time to Resolve | Unassigned
backend-payments  | 12   | 45       | 4.2 hours           | 0
backend-api       | 8    | 32       | 6.8 hours           | 0
frontend-ui       | 23   | 67       | 3.1 hours           | 0
frontend-checkout | 5    | 18       | 2.5 hours           | 0
unassigned        | 3    | --       | --                   | 3

Issue Linking

Connect Issues to Your Workflow

Most engineering teams don't manage their work in their error tracker. They use Jira, GitHub Issues, or Linear. JustAnalytics issue linking connects errors to your existing workflow tools.

Supported Integrations

Platform	Link Type	Features
GitHub Issues	Bidirectional	Create issue from error, auto-resolve on PR merge
GitHub Pull Requests	Reference	Link error to the PR that fixes it
Jira	Bidirectional	Create ticket from error, sync status
Linear	Bidirectional	Create issue from error, sync status
Shortcut	Outbound	Create story from error

Creating Linked Issues

From any error issue in JustAnalytics, click Create Issue to create a linked ticket in your project management tool:

Create Jira Ticket from Issue #1102

Project: BACKEND
Issue Type: Bug
Priority: High (auto-mapped from P1)
Title: PaymentProcessingError: Card declined
Description:
  Error occurring in production since March 28, 2026.
  47 events affecting 23 users.

  Stack trace:
  PaymentProcessingError: Card declined
    at processPayment (src/payments/stripe.ts:142)
    at checkoutHandler (src/api/checkout.ts:87)

  JustAnalytics Issue: https://app.justanalytics.app/issues/1102

Assignee: backend-payments (from ownership rules)
Labels: bug, production, regression

Bidirectional Sync

When the linked Jira ticket is moved to "Done," the JustAnalytics issue is automatically resolved. When the JustAnalytics issue regresses, the Jira ticket is reopened.

JustAnalytics Issue #1102 ←→ BACKEND-456

Status sync:
  JustAnalytics "Open" → Jira "To Do"
  Jira "In Progress" → JustAnalytics "In Progress"
  Jira "Done" → JustAnalytics "Resolved"
  JustAnalytics "Regression" → Jira "Reopened"

GitHub PR Auto-Resolution

Link an issue to a GitHub pull request. When the PR is merged, the issue is automatically resolved with a reference to the fix:

Issue #1102 resolved
  Fix: PR #342 "Handle card declined errors gracefully"
  Merged by: Sarah Chen
  Commit: abc123def
  Resolved in: v2.5.0

Shareable Error Links

Every error issue in JustAnalytics has a shareable link that includes full context:

https://app.justanalytics.app/share/err/abc123def456

This link shows:
  - Error message and stack trace
  - Occurrence count and affected user count
  - First and last occurrence timestamps
  - Browser and device breakdown
  - Related session replays
  - Timeline of status changes

Access Control for Shared Links

Configure who can access shared error links:

Setting	Access
Team only	Only authenticated team members
Anyone with link	No authentication required (limited info)
Public with full context	No authentication, full stack trace
Disabled	Sharing disabled for this issue

Embedding in External Tools

Shared links render rich previews when pasted into Slack, Discord, Notion, or other tools that support Open Graph metadata:

┌─────────────────────────────────────────┐
│ 🔴 PaymentProcessingError: Card declined │
│ 47 events · 23 users · First seen Mar 28 │
│ Status: Regression · Priority: P1         │
│ app.justanalytics.app                     │
└─────────────────────────────────────────┘

How It Compares to Sentry

Sentry is the gold standard for error tracking and issue management. Here's an honest comparison:

Feature	JustAnalytics	Sentry
Issue grouping	Fingerprint-based	ML-based (more advanced)
Issue merging	Yes	Yes
Issue unmerging	Yes	Yes
Merge suggestions	AI-powered	AI-powered
Similar issue detection	Embedding-based	ML-based
Regression detection	Yes	Yes
Resolve in version	Yes	Yes
CODEOWNERS integration	Yes	Yes
Custom ownership rules	Yes	Yes
Jira integration	Yes	Yes
GitHub integration	Yes	Yes
Linear integration	Yes	Yes
Shareable error links	Yes	Yes
Issue workflow (resolve/ignore/archive)	Yes	Yes
Alert rules on issues	Yes	Yes
Session replay on error	Built-in	Built-in
APM correlation	Built-in	Built-in
Log correlation	Built-in	Separate product
Language coverage	JS, Node.js	30+ languages
Pricing	Included in plan	Volume-based ($26/mo+)

Where Sentry wins: language breadth (JustAnalytics focuses on JavaScript and Node.js), ML-based grouping (more mature), and ecosystem maturity (larger community, more integrations).

Where JustAnalytics wins: unified platform (errors + analytics + APM + logs + uptime in one tool), simpler pricing (no per-event billing), and built-in features that Sentry charges extra for (session replay, performance monitoring, log correlation).

Setting Up Issue Management

Step 1: Configure Ownership

Connect your GitHub repository and upload your CODEOWNERS file, or define custom ownership rules in Settings > Issue Routing.

Step 2: Connect Your Project Management Tool

Go to Settings > Integrations and connect Jira, GitHub Issues, or Linear. Authorize the integration and map your projects.

Step 3: Configure Regression Alerts

In Settings > Alerts, create a rule for regressions:

Rule: Regression Alert
Trigger: Issue status changes to "Regression"
Actions:
  - Email issue owner
  - Post to #engineering Slack channel
  - Create Jira ticket (if not already linked)

Step 4: Review Merge Suggestions

Check the Merge Suggestions panel weekly to consolidate duplicate issues. This keeps your issue list clean and your metrics accurate.

Step 5: Enable Shared Links

In Settings > Sharing, configure the default access level for shared error links. We recommend "Team only" as the default with the ability to create public links on a per-issue basis.

Issue management is available today on all JustAnalytics plans. No additional configuration is needed for basic issue tracking -- just start capturing errors and issues are created automatically.

Start your 7-day free trial and manage errors like an enterprise team.