Telebugs 2.0 is out. It leaves more RAM for your applications, makes the useful parts of an error report easier to find, and lets you hand your coding agent the context it needs to investigate.
If you already run Telebugs, the important part is what you keep: your projects, reports, users, settings, and integrations. You update the existing installation. Your applications keep sending errors to the same place.
More room on your server
The Rust rewrite has a practical payoff: about 67% less RAM in a test with the same light workload. I compared the released 1.23.3 and 2.0.0 containers on the same machine, with the same data, CPU and memory limits, and default background workers.
While receiving errors and serving the interface, average memory use went from 580 MiB to 192 MiB. If Telebugs shares a server with your application, that is memory available for the application, its database, or the next service you want to run. The error tracker takes a smaller share of the machine it is helping you look after.
| Memory, MiB | 1.23.3 | 2.0.0 |
|---|---|---|
| During traffic | 580 | 192 |
| After processing | 678 | 207 |
These are averages from three runs per version on a local AMD64 Linux VM, each limited to 2 CPUs and 2 GiB of RAM. Each run received 300 errors at five per second while making 60 authenticated page requests; both versions processed every report. The second row measures the following 15 seconds with the ingestion queue empty. The measurement covers the whole application container and its background workers, using Docker's memory accounting, which subtracts inactive file cache. External notification delivery was not configured.
This measures a small installation under light traffic, not peak capacity or a minimum server requirement. Your data and workload will affect memory use. The gain here is RAM headroom; the 2.0 image itself is larger on disk.
Rewritten in Rust. Still one container.
Telebugs 1.x was a Ruby on Rails application. In 2.0, Rust handles the web server, error ingestion, background jobs, data migrations, and operational commands inside the container. The production image no longer includes a Ruby interpreter or Rails.
The deployment stays deliberately small: one Docker container, with SQLite for storage. You do not need to provision another database, add Redis, or learn a new installation process. Both Linux AMD64 and ARM64 are supported.
The browser side still uses server-rendered HTML, CSS, Turbo, and Stimulus. Menus, icons, and controls arrive as part of the page; JavaScript handles their interactions. This also removes the flicker caused by assembling parts of the interface after the page loads.
The hard part was preserving what was already running on people's servers. I used the Rails application as a reference for the Rust implementation, then tested the actual 2.0 release images on both architectures. That included upgrading from 1.23.3, processing reports and notifications, and exercising recovery with their existing data.
Sentry SDK compatibility, the REST API, MCP, source maps, notification channels, and retention controls all carry forward. These are parts of Telebugs you already had; the rewrite preserves them.
A clearer workspace
The project list is quieter. Search opens from a compact icon when you need it, and the date selector uses the same lightweight controls as the rest of the app. Project and report searches follow the same pattern, including filters for tags, contexts, and dependencies. The useful information stays visible; controls you rarely need stop competing with it.
On the all-errors and all-reports pages, project and date filters now sit above the results. The table keeps the focus on the errors. Rows and controls have been reworked for narrow screens too.
Filters above the results, with error details and report counts kept together. Shown with sample data.
Reports now have section navigation for moving between the backtrace, breadcrumbs, request details, and the other context an event contains. Source actions sit closer to the relevant frame. Nested values are easier to inspect, and breadcrumbs with very little information no longer leave large empty gaps. You can go straight to the evidence you need instead of scrolling through every section of a long report.
Move through the report's context from one workspace, or take its investigation prompt to your coding agent.
The project settings button is now beside the project name in the top navigation. It stays available as you move through that project's screens. There is one clear link back to the parent page, rather than an arrow and a label acting as separate links to the same destination.
Find the right error
Structured search now works in the project error view. You can combine words from the error with its status, severity, environment, server name, or tags. For example:
is:unresolved environment:production tags.component:apiThe status switcher and query work together: searching for resolved errors does not leave you stuck looking at the unresolved list. An exact Sentry event ID still takes you to the matching occurrence.
The command palette remains a shortcut to actions and navigation, with a smaller launcher that is distinct from page search. Shortcut hints are quieter, and opening a dropdown no longer stops its shortcuts from working just because the menu has focus.
Bring the right context to your coding agent
MCP was already in Telebugs. In 2.0, the connection becomes more useful at two specific moments: setting up a project and investigating an error.
Investigate the report you are actually looking at
Error groups and individual reports now offer a copyable investigation prompt. Give it to your coding agent with Telebugs MCP connected, and it can retrieve the group, report details, notes, and source links in one tool call. You no longer have to assemble that context by hand and explain which occurrence you meant.
The distinction between a group and an occurrence matters. If you copy the prompt from an older report, the agent gets that exact occurrence. It does not silently substitute a newer one. Starting from a group chooses a recent report with useful application frames when one is available.
The prompt asks the agent to check the repository and reported release, investigate the cause, and test a focused fix. It also tells the agent to treat event contents as evidence, not instructions. Preparing a fix does not automatically resolve the error or deploy anything.
Verify the first error from a new project
The setup prompt gives your agent a way to request the project's actual DSN and SDK guidance, configure error reporting, and check that a test event arrived. It checks for the specific test error your agent sent, so an unrelated error is not mistaken for a successful setup. That closes the loop between adding an SDK and knowing Telebugs received its first event.
You can copy either prompt before connecting MCP. Running it requires the connection, and read access is enough for retrieving setup details and investigation context. Writing a note or changing an error's status still requires write access.
The connection screen now explains permissions in plain language, and connected apps are easier to review and revoke from settings.
Settings with less friction
Account, project, team, notification, and instance settings now share a consistent layout. Related settings have their own sections, with the same navigation, controls, and feedback across the app.
Longer configuration forms, including email delivery settings, open inline instead of filling a dialog. Validation messages sit next to the field that needs attention. Save and Cancel remain together, and canceling returns you to the setting you were viewing. The surrounding setting stays visible while you edit, so it is easier to understand what the change affects.
Edit a setting in context, without a separate dialog. Here, source code linking is expanded on the project's General page.
Creating a project is easier too: the platform picker is searchable, so you can type your language or framework instead of scrolling through the whole list.
You can also pause all project emails and push notifications with one account-wide switch. Your individual project preferences stay saved for when you turn notifications back on.
The small things add up
Much of this release is work you should feel without having to think about it:
- Menus share spacing, selection colors, and shortcut styling in light and dark mode.
- Search fields and dialogs animate in and out, with reduced-motion preferences respected.
- Opening a dialog keeps the page's scrollbar in place, so the content does not jump sideways.
- Copy and token-regeneration feedback changes the button's icon without squeezing the adjacent input.
- Profile photos appear throughout account settings, and the default avatar has a consistent size.
Turning off artifact retention also stops automatic artifact cleanup when a new release is uploaded.
Updating from 1.x
On the server running Telebugs, start with:
telebugs updateThe updater checks your license and handles the application and data upgrade. You keep your existing projects, report history, users, credentials, and settings. Your SDK DSNs and integrations do not need to be reconfigured for the standard supported installation.
After updating, run telebugs version to see the installed
application and CLI versions.
- Already on an active updates-and-support plan? 2.0 is included. You do not need to buy it again.
- Have an original 1.x license? The optional loyalty upgrade is $99 for a year of updates and support, renewing at $99/year. There is no second license fee. The updater gives you the checkout link; run it again after purchasing.
- New to Telebugs? A new self-hosted purchase is $299, including the perpetual license and the first year of updates and support, then $99/year.
Prices are before tax. Active updates coverage includes future major releases too. If you cancel, you keep the versions covered by your plan. If you stay on 1.x, your existing license remains valid.
The updater also saves a recovery snapshot before the upgrade. If you need to return to 1.x, the current CLI's rollback restores the matching application and data snapshot and pauses automatic updates. Restoring rewinds the data to that snapshot: reports and settings changes made afterward will not be present in the restored installation.
Read the 2.0.0 changelog for the detailed changes, or explore the live demo to get a feel for the interface.