Sentry SDK compatible | Self-hosted error tracking

Use the SDKs you already know

Telebugs speaks the Sentry protocol. Every official and community Sentry SDK sends error reports as a well-specified JSON envelope. Telebugs accepts exactly those payloads.

No forks. No custom SDKs. No rewriting your error handling.

If your codebase already uses a Sentry SDK (or you were planning to adopt one), you can send those same events to a Telebugs server running on your infrastructure in minutes.

Supported languages and frameworks

Sentry maintains excellent SDKs for the platforms developers actually use. Telebugs works with all of them:

• JavaScript / TypeScript: Browser, Node.js, Next.js, React, Vue, Svelte, Solid, Astro, and more
• Ruby: Rails, Sinatra, any Rack app (via sentry-ruby)
• Python: Django, Flask, FastAPI, Celery, serverless, etc.
• PHP: Laravel, Symfony, plain PHP
• Java / Kotlin: Spring Boot, Android, plain Java
• Go, .NET, Swift, Dart/Flutter, and many others via official or community SDKs

See the full Sentry SDK list and the Telebugs supported platforms appendix. If a Sentry SDK exists for it, Telebugs will accept the events.

How to migrate (or adopt) in three steps

1. Keep your code exactly as it is. The Sentry SDK initialization, context, breadcrumbs, user info, and custom tags all continue to work.
2. Create a project in Telebugs and copy its DSN (the URL that looks like https://[email protected]/api/v1/sentry_errors/123).
3. Update the DSN in your Sentry.init (or equivalent environment variable / config file). Deploy. Errors start flowing to your server.

Example for a Rails app (the same pattern applies everywhere):

gem "sentry-rails"

# config/initializers/sentry.rb
Sentry.init do |config|
  config.dsn = "https://[email protected]/api/v1/sentry_errors/1234"
  config.environment = Rails.env
  # ... your existing config (breadcrumbs, traces_sample_rate, etc.) stays the same
end

The same one-line DSN change works for Python, JavaScript, Go, PHP — whatever SDK you were (or are) using.

Full integration guides live in the Telebugs manual and the official Sentry platform docs (just substitute your Telebugs DSN).

Why Sentry SDK compatibility matters

The Sentry SDK ecosystem is one of the best parts of the error-tracking world: mature, well-documented, actively maintained, and present in millions of codebases. By speaking the same wire format, Telebugs lets you keep that investment while moving the server-side to something you control.

• No vendor lock-in on the client side.
• Instant familiarity for any developer who has used Sentry before.
• Easy to run a hybrid setup (Sentry in one environment, Telebugs in another) or a full migration.
• Future-proof: as Sentry improves their SDKs, Telebugs continues to benefit because we follow the same documented envelope format.

You do not need to have used Sentry before. Many teams adopt Telebugs as their first error tracker and simply follow the Sentry SDK docs for their stack — the DSN is the only Telebugs-specific piece.

What you gain on the server side

Once the events arrive, Telebugs gives you everything you actually need to act on errors, without the bloat:

• Automatic grouping with smart defaults (stack trace first) plus custom fingerprinting and manual merging.
• Rich context: highlighted in-app frames, full backtraces, breadcrumbs, request data, user, extras, and release info.
• Releases + source map support so production stack traces point at real source lines.
• Flexible notifications (email, PWA push, Slack/Discord webhooks) with rules so you only hear about what matters.
• Collaboration features: notes, ownership, bulk resolve/unresolve, muting and snoozing.
• Data retention policies you control, plus a full REST API.

All of it runs in a single Docker container. One command to install. Updates within a major version are free. Pay once ($299.99), own it forever, no event quotas, ever.

Frequently asked questions

Do I have to change any error-reporting code?

No. The only change is the DSN value passed to the Sentry SDK. Everything else (context, tags, breadcrumbs, sampling, etc.) continues to work as before.

Will Telebugs support future Sentry SDK features?

We track the public Sentry envelope specification and the behavior of the official SDKs. New optional fields that don't break existing ingestion are generally supported automatically. If you hit an edge case, let us know — compatibility is a core commitment.

Can I run Telebugs alongside Sentry?

Yes. Many teams use Telebugs for staging, development, or as an unlimited backup, while keeping Sentry for production or specific projects. Or run Telebugs everywhere and turn off the Sentry SaaS ingestion.

If you're evaluating self-hosted Sentry itself and running into the complexity, hardware, and maintenance issues, we wrote a full comparison here: Self-hosted Sentry too complex?

What about importing historical data from Sentry?

Sentry does not make bulk export easy. Telebugs does not currently offer an official import tool. Most teams start fresh (errors are transient signals) or write a small one-off script using the Sentry API + Telebugs REST API if they truly need the history.

Is Telebugs only for people who used Sentry before?

Not at all. The Sentry SDKs are simply the best-documented, most widely supported way to get structured error data from almost any runtime into a server. You can adopt Telebugs as a brand-new error tracker and follow the Sentry platform docs for your language — the only Telebugs-specific value is the DSN you paste in.

Ready to point your SDKs at a server you own?

Read the Sending your first error report guide, pick your platform from the supported platforms list, or get Telebugs and be up and running in minutes.