Sentry SDK Compatible Error Tracking | Telebugs

Quick answer: can I keep my Sentry SDKs?

Yes, for error tracking. Telebugs accepts Sentry SDK error events, so most applications can keep the same SDK package, initialization code, breadcrumbs, tags, user context, release names, and environment settings. The change is the DSN: point the SDK at your Telebugs server instead of Sentry.

This matters because Sentry’s SDK ecosystem is broad and well documented. Sentry’s own platform docs list SDKs for popular runtimes such as JavaScript, Python, Ruby, Go, PHP, Java, .NET, Android, Apple platforms, and more. Sentry’s developer docs also describe event payloads as the data that clients, often through SDKs, send to the server, and describe envelopes as the transport format used for ingestion.

Sources: Sentry platform docs, Sentry event payload docs, and Sentry envelope docs.

What Sentry SDK compatible means

Sentry SDK compatible does not mean Telebugs tries to clone the entire Sentry product. It means the application-side error reporting path stays familiar while the backend changes.

• Keep the SDK package. Continue using the official Sentry SDK for your language or framework.
• Keep your instrumentation. Existing calls, breadcrumbs, tags, extras, user context, release names, environments, and custom fingerprints can keep flowing.
• Change the DSN. Point the SDK at the Telebugs project DSN and send a real test exception.
• Use Telebugs for error tracking. Telebugs focuses on exceptions, grouping, stack traces, breadcrumbs, releases, sourcemaps, notifications, notes, retention, REST API access, and MCP error tracking.
• Do not assume every Sentry product feature. Tracing, profiling, replay, logs, and Sentry’s hosted AI products are separate observability features, not the core error-reporting migration path described here.

How Telebugs is different by design

Telebugs is built for teams that like the Sentry SDK path but want a smaller, self-hosted backend for errors. The difference is what happens after the events arrive and what it costs you to operate the system.

Aspect	Sentry SDKs + official backends (hosted or self-hosted)	Sentry SDKs + Telebugs
Client code changes	Sentry SDK setup, DSN, release, environment, breadcrumbs, tags, user context, and extras.	Keep the SDK setup and change the DSN for error reporting.
Error payloads	Sentry SDKs send event payloads and envelopes to Sentry ingestion endpoints.	Telebugs accepts Sentry-shaped error events and turns them into grouped issues, reports, stack traces, breadcrumbs, and alerts.
Server architecture	Hosted Sentry is a broad SaaS platform. Self-hosted Sentry uses Docker Compose, requires at least 4 CPU cores and 16 GB RAM plus 16 GB swap, and recommends 32 GB RAM.	Single Docker container. One command install. Smaller operating surface for teams that mainly need error tracking.
Cost model	Hosted Sentry uses plan and usage-based pricing. Self-hosted Sentry removes SaaS billing but adds infrastructure and maintenance work.	One-time $299 USD license. Self-hosted only. No recurring Telebugs fee and no Telebugs event quota.
Support	Hosted: vendor support depending on plan. Self-hosted Sentry docs say there are no guarantees or dedicated support.	Email support included with every purchase. No tiers or upsells.
Scope & focus	Broad application monitoring and observability: errors, tracing, replay, profiling, logs, cron, uptime, dashboards, AI features, and more.	Focused error tracking: collect, group, inspect, notify, collaborate, retain, purge, and expose error context through API and MCP.
Key strengths	Mature SDK ecosystem, rich context, broad platform coverage, hosted convenience, and full observability features.	Keep the SDK investment while moving error tracking to a simpler self-hosted backend with included support and predictable pricing.

Sources for the Sentry-side facts above: Sentry platform docs, event payload docs, envelope docs, self-hosted docs, and pricing page.

When Sentry SDKs with Telebugs make sense

Sentry SDK compatibility is useful when you want to change the destination without rewriting application instrumentation.

• You (or your team) are already deeply familiar with the Sentry SDKs and want to keep that code and mental model while changing only the backend.
• You need a cautious migration path, such as testing Telebugs in staging or one low-risk production service before moving more projects.
• You value the broad language/framework coverage and rich context the SDKs provide, but you want a focused self-hosted backend for errors.
• You are evaluating self-hosted options and the "just change the DSN" story removes a major migration barrier.
• You want error data on your own infrastructure while preserving the breadcrumbs, tags, releases, and user context your apps already send.

For teams that want SDK familiarity plus a smaller, owner-operated backend, Telebugs is a strong fit.

How to migrate (or adopt) in three steps

1. Keep your SDK instrumentation in place. Your Sentry SDK initialization, context, breadcrumbs, user info, release, environment, and custom tags can stay in the app.
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 call, environment variable, or config file. Deploy and send a test exception. New errors should flow 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 error-tracking config stays the same
end

The same pattern applies to Python, JavaScript, Go, PHP, .NET, and other Sentry SDK integrations that send standard error events.

For Ruby apps, if you want a vendor-neutral layer on top of the Sentry-compatible SDKs (so you can easily switch between backends like Telebugs and others without code changes), see the Lapsoss project and the Telebugs blog post introducing it.

Full integration guides live in the Telebugs manual and the official Sentry platform docs (just substitute your Telebugs DSN). If you are switching existing projects from Sentry, use the Sentry migration guide as your rollout checklist.

Supported languages and frameworks

Sentry documents SDKs for the platforms developers actually use. Telebugs supports the Sentry error-event path for these SDKs:

• JavaScript / TypeScript: Browser, Node.js, Next.js, React, Vue, Svelte, Solid, Astro, and more
• Ruby: Rails, Sinatra, any Rack app (via sentry-ruby). For a vendor-neutral abstraction layer on top of Sentry-compatible SDKs (to easily switch providers like Telebugs), see the Lapsoss project and the Telebugs blog post.
• 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. For unusual community SDKs or advanced SDK features, send a real test exception before migrating a critical service.

What you gain on the server side

Once error events arrive, Telebugs gives your team the focused workflow needed to act on them:

• 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, Teams) with rules so you only hear about what matters. See the notifications and rules guide.
• Collaboration features: notes, ownership, bulk resolve/unresolve, muting and snoozing.
• MCP support for AI coding tools, so authorized clients can inspect real production error context without copying stack traces by hand. See MCP error tracking.
• Data retention policies you control, plus a full REST API. See the retention and compliance guide.

All of it runs in a single Docker container. Updates within 1.x are included, and the pricing model stays separate from Telebugs event volume.

Frequently asked questions

Is Telebugs Sentry SDK compatible?

Yes, for error tracking. Telebugs accepts Sentry SDK error events, so most applications can keep their existing SDK setup and change the DSN to point at a Telebugs project.

Do I have to change any error-reporting code?

For basic error reporting, usually no. The main change is the DSN value passed to the Sentry SDK. Your error context, tags, breadcrumbs, release, environment, user data, and extras can continue to flow.

Is Telebugs a drop-in replacement for all Sentry features?

No. Telebugs is focused on Sentry SDK compatible error tracking. It is not a replacement for every Sentry observability product such as tracing, profiling, replay, logs, uptime monitoring, cron monitoring, or hosted AI features.

Which Sentry SDKs work with Telebugs?

Telebugs works with Sentry SDKs that send standard Sentry error events and envelopes. Common JavaScript, Python, Ruby, Go, PHP, .NET, Java, and mobile SDK paths are good fits; for unusual community SDKs, test a real exception first.

Will Telebugs support future Sentry SDK features?

Telebugs tracks the public Sentry event and envelope formats for error reporting. New optional fields that do not break existing ingestion are often harmless, but compatibility is focused on production error tracking rather than every new Sentry product feature.

Can I run Telebugs alongside Sentry?

Yes. You can migrate project by project, start in staging, or point one low-risk service at Telebugs first. Some teams keep Sentry for specific projects while moving core error tracking to Telebugs.

If you're comparing Telebugs with hosted Sentry, start with the Sentry alternative page or the broader error tracking alternatives hub. For the category-level decision, see self-hosted error tracking. If EU data storage or self-hosting in Europe matters, see European Sentry alternatives. 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?

Telebugs does not currently offer an official bulk import tool for historical Sentry issues. Most teams start fresh for new errors and keep the old Sentry project available temporarily if they need to reference past reports.

Can I switch back to Sentry later?

Yes. Because your application-side instrumentation still uses Sentry SDKs, switching the error destination later is usually another DSN change. Historical data will remain in whichever backend received it.

Does Sentry CLI still work for releases and sourcemaps?

Yes for the Telebugs-supported release and sourcemap workflow. If you already upload sourcemaps during deploy, point the relevant configuration at your Telebugs project and verify a minified test error.

Is Telebugs only for people who used Sentry before?

No. You can adopt Telebugs as a brand-new error tracker and follow the Sentry platform docs for your language. The Telebugs-specific value is the project DSN you paste into the SDK configuration.

Ready to point your SDKs at a server you own?

Read Sending your first error report, pick your stack from supported platforms, or request a private demo. When you are ready, buy Telebugs.