Telebugs 1.21.0: Hosted Source Maps and Better Error Grouping

Telebugs 1.21.0 is out. This release takes on two error-tracking problems that are easy to explain and surprisingly easy to get wrong: turning a minified JavaScript stack trace back into readable source code, and deciding whether two noisy reports are really the same error.

Telebugs can now find source maps on public hosts that you allow. Its new grouping algorithm focuses on the parts of an error that stay the same. It ignores line shifts, generated asset names, request IDs, and other details that can change each time the same problem happens.

I also improved notifications. Projects can now send alerts only for fatal and error events. Telebugs retries failed deliveries before it asks for attention, and regression alerts include more context about what reopened.

The Telebugs command-line tool now also supports backups and restores for moving or recovering an installation.

Use the Source Maps You Already Host

Until now, the reliable Telebugs path for source maps was to upload them with a release, as described in the 1.5.0 source map announcement. That remains the right choice for private maps. But many applications already publish a generated JavaScript file and its map together on a public asset host. Uploading the same files again just for Telebugs is extra work.

In 1.21.0, a project admin can authorize an exact public HTTPS origin, such as https://assets.example.com. When a JavaScript report points there, Telebugs can find the map advertised by the generated file, cache it, and resolve the stack trace in the background.

The rules are strict on purpose. Telebugs does not make a request until an admin adds an origin. Private network addresses, credentials, custom headers, and redirects are not part of the feature. There is also an instance-wide off switch, while uploaded release artifacts continue to work as before.

Each JavaScript report now shows its source map status. If a deploy was incomplete or an asset host was briefly unavailable, an admin can fix the deployment and retry from the report instead of waiting for a new occurrence.

Group the Error, Not the Noise

Grouping errors is hard. Group too aggressively and two different bugs become one confusing pile. Group too literally and one bug becomes twenty groups because a line moved, a JavaScript filename gained a new content hash, or an exception message included a new order number.

The new grouping algorithm uses the parts that usually stay the same after a deploy: exception type, application frames, functions, paths, and source context. It understands common deploy paths and generated asset names, prefers the crashed or current thread, and ignores values such as UUIDs, timestamps, email addresses, and request IDs when it has to group by a message.

It stays conservative where meaning matters. Different exception types, functions, source paths, HTTP status codes, database error codes, and custom Sentry fingerprints remain distinct. Existing groups are not rewritten; incoming reports move to the new rules without any extra work.

The result should be fewer duplicate groups after ordinary deploys, without merging unrelated errors. That is the whole job.

Notifications That Earn Your Attention

Not every captured event deserves to interrupt someone. A project can now keep warning, info, debug, and sample-level events available in Telebugs while sending notifications only for fatal and error events. It is one switch in project notification settings, and it applies to the notification rules already configured there.

Delivery is more reliable too. Email, push, and webhook notifications retry temporary failures. If a delivery eventually fails for good, admins see a banner with a direct path to the failed jobs and the recovery guide. A notification system should not quietly lose the notification that says production is on fire.

Regression emails and custom webhooks now explain which report reopened the error, which release it came from when available, when the report arrived, and who previously resolved the error. A useful alert should include the basic facts.

Find the Exact Occurrence

Sentry SDKs attach an event ID to an occurrence. Telebugs now preserves that value, shows it as the Occurrence ID on the report, and lets you copy it or paste it into project search to jump straight back to the report.

The same ID also prevents a retried SDK delivery from creating a duplicate report. One occurrence stays one occurrence, even when the network has other ideas.

Use the New Features From MCP and REST

I introduced the REST API in 1.16.0 and MCP support in 1.17.0. This release keeps both up to date with the rest of Telebugs.

Scripts can now work with hosted source map settings, the new notification filter, source map retries, and occurrence IDs. Connected AI tools can use occurrence IDs to find exact reports and see the new grouping and source map information while investigating an error.

Reports That Are Easier to Scan

Error reports now fit more useful information on the screen. Affected-user details, tags, contexts, and dependencies take up less space, so reports are easier to scan and you spend less time scrolling.

I also removed source actions from backtrace frames when Telebugs cannot build a usable destination. A button that cannot take you anywhere should not be there.

Back Up and Restore Telebugs

The Telebugs command-line tool can now create, check, and restore a complete backup. For example:

telebugs data backup /mnt/offsite/telebugs-production
telebugs data verify /mnt/offsite/telebugs-production.tar.gz

To recover Telebugs on a replacement server, copy the archive there and run:

sudo telebugs data restore /mnt/offsite/telebugs-production.tar.gz

The backup includes Telebugs data, recovery secrets, and the exact application version needed to restore it. Keep it encrypted and away from the Telebugs server. The backup and restore guide explains how to test a recovery safely. The telebugs command reference lists every option.

A Simple Readiness Check

Telebugs already had /up, which tells you that the web process is running. The new /ready check goes further. It checks that the databases, storage, disk space, error intake, and background workers are ready to do their jobs.

Use /up to decide whether the web process needs a restart. Use /ready for deployment and monitoring checks. The new telebugs status command shows admins why an instance is not ready and warns about permanently failed notification deliveries. The health and status guide has the full list of checks.

The Right Timezone From the Start

Project timezone detection now understands the full set of current IANA timezones as well as older names that browsers may still report. New projects are more likely to start with the correct timezone selected, and existing projects that use an older alias keep the right selection when you edit them.

Timezones are the sort of feature that feels finished right up until one city gets renamed. Telebugs now handles that transition without asking you to know which spelling your browser prefers.

After Upgrading an Existing Installation

Instance admins may see one or two service messages after upgrading. They are one-time maintenance tasks, not migration failures, and you do not need to take Telebugs offline to run them.

Earlier versions could remove expired reports without refreshing the stored report counts and the First seen and Last seen times shown for an error. Version 1.21.0 fixes future cleanup and adds an Update report counts and times task to repair existing values from the reports still stored in Telebugs. It does not delete reports or change mute settings.

Existing reports also predate the clearer source map statuses in this release. The Finish updating source map statuses task updates them in small background batches and resumes where it stopped if interrupted. Telebugs remains available while either task runs. Large installations should start them when traffic is low.

Wrapping Up

That is the shape of 1.21.0: use the source maps your application already serves, keep variations of the same error together, make notifications both quieter and harder to lose, back up and restore an installation, and start projects in the right timezone.

Full details are in the changelog. If something feels off, write to [email protected]. I am also on X at @kyrylo and @TelebugsHQ.