Leaving Sentry?
Keep the SDKs you already installed. Point one app at Telebugs and send an error. See what it’s like to fix a bug here before moving the rest.
Start with one app
Create a project in Telebugs and copy its full DSN, including the key and project path. Replace the Sentry DSN in a staging app, then restart or redeploy it. Your existing Sentry SDK can stay. The reports now have a different destination.
Our language and framework guides show where that configuration lives. For a frontend app, remember that the DSN may be baked into the build. For background workers, make sure they pick up the new configuration, too.
This is a move for error tracking. If you rely on Sentry’s tracing, profiling, or session replay, decide where those workflows will live before switching. The Sentry comparison explains the broader decision.
Follow an error all the way through
Trigger a controlled error. Open it in Telebugs and read it as if a customer had just reported a problem. Is the backtrace useful? Are the environment, release, tags, and breadcrumbs you rely on present? Has sensitive data stayed out?
For JavaScript, point your source-map upload step at Telebugs and check a production build. Readable frames are worth testing now. Telebugs processes source maps after grouping; remapping a trace doesn’t change the issue it belongs to. The source-map walkthrough shows the result.
Configure a notification and make it fire. Send a second occurrence, resolve the error, and trigger it again. Try a worker failure or a browser error if those matter to your app. You’re checking the experience your team will use every day.
Your Sentry history stays in Sentry
Changing a DSN routes new reports. It doesn’t import old issues, comments, assignments, or attachments. Telebugs has no built-in historical Sentry import. Keep access to Sentry for old reports you still need.
Notification rules, integrations, and team access need setting up in Telebugs. Grouping can differ, too. Start with the rules that help your team act; moving is a good moment to leave behind alerts everybody ignores.
Move when you like what you see
Once staging looks right, move one production app. Keep the old DSN and watch the reports and notifications through a normal working day. Move the next app when you’re comfortable with the first.
To roll back, restore the old Sentry DSN and redeploy. Reports already sent to Telebugs stay in Telebugs; they aren’t copied back to Sentry. Keep any source-map or integration configuration you need for the old destination, too.
Ready to try your own app? Pick Self-hosted or Managed. Either way, you get help from the person building Telebugs. Bring a real error. It’s the best way to see whether the software suits you.