Error Grouping Explained | Telebugs

Why error grouping matters

When an error happens in production, it rarely happens just once. A single bug can generate hundreds or thousands of nearly identical reports - the same stack trace, the same message, the same context - just with slightly different user data or timestamps.

Without smart grouping, your error list becomes noise. You waste time triaging duplicates instead of fixing root causes. In high-volume apps this quickly becomes unmanageable, especially if you're paying per event or fighting alert fatigue.

Telebugs solves this at the core: it automatically groups similar reports into issues so you see one clear problem instead of a flood of reports. The grouping relies on straightforward, battle-tested techniques such as prioritizing frames from your own code, using exception type and message as signals, and applying sensible fallbacks. These are implemented efficiently in a lightweight system, so grouping stays fast and useful without adding operational overhead.

How Telebugs groups errors

Telebugs uses a combination of straightforward, proven heuristics that work well out of the box for most applications:

• Stack trace priority: In-app frames (your code, not libraries or framework internals) are weighted heavily. Filename + function + line number form a strong signal.
• Exception type and message: When stack traces are similar or absent, the error class and message help group related problems.
• Fallbacks: If needed, it falls back to the raw error message or other payload fields.

The result: the same ActiveRecord::RecordNotFound from a missing record looks like one issue even if it fires from dozens of different user requests. A transient network error in a background job gets grouped instead of creating hundreds of separate entries.

This default behavior is deliberately simple and effective. The techniques are performant by design and follow the same philosophy as the rest of Telebugs: do the right thing for 95% of cases with zero configuration, then give you escape hatches for the rest.

Custom fingerprinting

Sometimes the defaults aren't quite right for your codebase. Telebugs gives you two powerful ways to take control:

Custom fingerprints via the SDK

You can tell the Sentry-compatible SDK exactly how to group an error by passing a fingerprint array when capturing it. Everything with the same fingerprint ends up in the same issue.

# Ruby / Rails example
Sentry.capture_exception(e, fingerprint: ["payment-failure", current_action])

# Python / Django example
sentry_sdk.capture_exception(e, fingerprint=["checkout-error", str(user_id)])

This is perfect for business-level grouping: "all payment failures", "all errors in the checkout flow for this tenant", "all validation errors on this specific form", etc. It works the same way whether you're using Telebugs, Sentry, or another compatible backend.

Manual merging in the UI

When similar issues end up as separate groups (common after a refactor or when stack traces differ slightly), you can merge them directly in the Telebugs interface:

1. Open the main (target) issue.
2. Click Merge.
3. Paste the URLs of the groups you want to combine.
4. Confirm.

Future reports matching either original group will now land in the combined issue. The action is irreversible, so use it when you're confident the issues represent the same underlying problem.

Grouping details are also visible on each issue so you can understand exactly why Telebugs decided two reports belong together (or didn't). This transparency helps when tuning custom rules.

Grouping across the stack

Because Telebugs is fully compatible with Sentry SDKs, the same grouping logic applies whether the error comes from:

• Django, Flask, FastAPI, or plain Python
• Rails, Sinatra, or other Ruby apps
• React, Next.js, Vue, or browser JavaScript
• Background jobs (Celery, Sidekiq, ActiveJob, etc.)
• Mobile, serverless, or anything else sending via a Sentry SDK

One consistent grouping engine for your entire company, no matter the language or framework. This is especially valuable when you're running Telebugs as a central hub for multiple teams or as a cost-controlled backup to a primary Sentry instance.

Self-hosted grouping

In bloated self-hosted Sentry setups, grouping is one of many features that ends up buried under infrastructure complexity, high resource usage, and maintenance overhead. Teams often end up with either too many issues (poor defaults) or too few (overly aggressive merging) because tuning is painful.

Telebugs keeps the powerful parts of grouping while removing the surrounding pain:

• Single-container simplicity means you actually have time to look at your issues instead of babysitting Kafka/ClickHouse/etc.
• One-time purchase removes the incentive to let noise pile up (no per-event billing pressure).
• Low resource requirements mean you can afford to run it on cheap hardware or as a always-on staging/dev backup.

The result is grouping that helps instead of getting in the way. This is exactly what most teams actually need from an error tracker.

Frequently asked questions

Can I turn grouping off?

No. Ungrouped errors are almost never useful at scale. If you truly need every individual report as a separate issue, you can achieve something close with very unique custom fingerprints, but we strongly recommend against it.

How does it compare to Sentry grouping?

Very similar by design. Because we accept the same Sentry SDK payloads and follow the documented fingerprinting behavior, most projects see comparable results with zero changes. The main differences are in the surrounding experience: the grouping is delivered through simple, performant techniques in a lightweight system with no complex infrastructure or per-event costs to work around.

What if grouping is too aggressive or not aggressive enough?

Use custom fingerprints in your SDK calls for business-level grouping, and use the manual merge tool in the UI for one-off cleanups after deploys or refactors. Most teams find the defaults plus occasional custom fingerprints cover 95%+ of cases.

Does grouping work for JavaScript minified code?

Yes. When you upload source maps (via releases or the API), Telebugs can map frames back to original source before applying grouping rules. This dramatically improves grouping quality for frontend errors. See the releases + sourcemaps documentation for setup.

Ready to stop drowning in duplicate errors?

Read the Telebugs manual for full grouping and fingerprinting details, or get Telebugs and start seeing clean, actionable issues in minutes.