urgentry vs Telebugs: two takes on one-off, self-hosted Sentry-SDK error tracking

What the two products are

Telebugs is a self-hosted error tracker built by Kyrylo Silin and announced on X on June 1, 2026. The backend is Ruby on Rails. It is sold as a one-time license at $299.99 per domain, with free updates inside the 1.x major version and a possible upgrade fee at the next major. It is shipped as a Docker container, runs on a Linux server, and accepts events from the Sentry SDKs the team has tested against.

urgentry is a Sentry-compatible error tracker built as a single Go binary against SQLite by default, with Postgres optional. It is distributed under the Functional Source License (FSL-1.1-Apache-2.0), which permits use, inspection, and modification from day one and converts to a permissive Apache 2.0 license after two years. urgentry implements 218 of the 218 documented Sentry REST API operations and accepts the standard Sentry envelope at /api/<project>/envelope/.

The same problem statement sits behind both: Sentry self-hosted is too heavy to run, and Sentry SaaS bills grow faster than the value the team perceives. Both tools target the same instinct — we just want errors, on our own server, without twenty containers.

The wire surface they share

Both products are Sentry-SDK-compatible. The phrase has a precise meaning: the SDK serializes events into the Sentry envelope format and POSTs them to a URL derived from the DSN. Any backend that accepts that envelope, parses it, and stores the result is wire-compatible. The application code does not change.

The Telebugs landing page lists tested SDKs for React, Next.js, Vue, Angular, Ruby on Rails, Laravel, Solid, Svelte, Astro, Go, Swift, Django, .NET, ASP.NET Core, and Spring Boot. urgentry tests against the same official SDKs plus the OTLP-native path for OpenTelemetry shops; the SDK list is functionally identical because both products consume the same upstream envelope format.

Practically:

// Identical SDK code for either backend
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
});

The diff between “running Telebugs” and “running urgentry” from an SDK perspective is the value of SENTRY_DSN. Nothing else.

One nuance: Telebugs handles the SDK envelope as its primary ingest path. urgentry accepts the same envelope and an OTLP path for teams already running an OpenTelemetry Collector. If your stack is OTel-first and you want errors to ride alongside traces, urgentry has the second door. If your stack is Sentry SDK and only Sentry SDK, the two are functionally equivalent on ingest.

Deployment shape

The biggest practical difference is the shape of the thing you actually run on the server.

Telebugs is a Docker container that wraps the Rails app, a worker process, and a relational database. The Rails runtime is an established but heavyweight stack: Ruby interpreter, Bundler, ActiveRecord, the Rails request pipeline, Sidekiq or a similar background worker, and a Postgres dependency. The deployment minimum the project publishes is 1 GB of RAM and one CPU core. That is a real budget — you cannot park a Rails app inside 256 MB — but it is well inside what a $5 VPS or a hobby server provides. Updates are handled through container pulls inside the 1.x line.

urgentry is one Go binary. There is no language runtime to install, no container required (though one is published), no companion services. The binary embeds the HTTP server, the ingest pipeline, the issue store, the UI, and the migration runner. SQLite is the default state store and lives in one file on disk; Postgres is supported but optional. A typical install:

curl -L https://urgentry.com/download/urgentry -o urgentry
chmod +x urgentry
./urgentry serve --data ./data

That is the entire install. No docker compose up, no Ruby version manager, no migration script to remember to run. The trade-off is that you lose the Docker layer of abstraction some teams want for upgrades and isolation. If your existing operational habit is “everything is a container”, Telebugs slots into that habit; if your habit is “ship a binary and write a systemd unit”, urgentry slots into that one.

Both fit on the same class of hardware. Both are within the same order of magnitude of resource consumption. The difference is in the operational surface you inherit: Rails app + worker + database vs static binary + one file.

License and pricing

Telebugs is proprietary software sold once per domain at $299.99. The license permits internal modifications but forbids redistributing the code in any form outside Telebugs itself. Major version upgrades may carry a fee; updates inside 1.x are included.

urgentry is FSL-1.1-Apache-2.0. You can read the source, modify it for your own use, and run it without paying. The Functional Source License imposes one restriction: you cannot offer urgentry as a competing commercial service for the first two years after each release. After two years, that release becomes Apache 2.0 with no restrictions. For an internal error tracker, the FSL is practically equivalent to a permissive license — the carve-out only bites if you are trying to be a competitor.

The pricing comparison against Sentry SaaS is where both tools win obviously. A team paying $1,200 a year for Sentry Team plan is paying roughly 4x the lifetime cost of one Telebugs license in year one, and infinitely more than urgentry, every year. The TCO comparison we publish at /guides/cost/self-host-economics/ goes through this in detail; the short answer is that the bill stops once you self-host either way, and the engineer-hours line item is the one that decides the rest.

What you are choosing between, then, is not “cheap vs free” in any meaningful sense. It is “a paid product with a defined vendor relationship” vs “a permissively licensed binary with public source.” Some teams prefer the former because the support expectation is clearer. Some teams prefer the latter because they want to read the code that handles their exception data.

Throughput and the storage shape

Telebugs publishes performance estimates of about 30 errors per second on a 2-core machine, 60 on 4 cores, and 240 on 16 cores. urgentry’s published benchmark sustains roughly 400 events per second on a $5 VPS (1 vCPU, 1 GB RAM) writing to SQLite; the reproducible test harness is documented in our benchmarks guide.

Throughput claims from any vendor deserve scrutiny. The reading-vendor-benchmarks guide we publish lists the five conditions you should check before trusting either number. The honest summary for most teams is that both products handle hundreds of events per second on small hardware, and the rate at which errors actually arrive in production for a typical web app is one or two per second on average with spikes during incidents. Neither product is the bottleneck in real workloads.

The storage model differs. Telebugs uses a relational database under Rails — Postgres in the documented setup — with the usual ActiveRecord schema. urgentry uses SQLite by default; events, issues, releases, deploys, and the tag index all live in one database file. For a single-host deployment, SQLite has fewer moving parts. For a team that already runs Postgres for everything else and prefers symmetry, urgentry supports Postgres too, and Telebugs uses it by default.

The product surface beyond ingest

Both products do the four things every error tracker does: capture events, group them into issues by stack signature, alert on new and regressed issues, and present them in a searchable UI.

Telebugs documents email alerts and Progressive Web App push notifications, team management, multi-project support, and the standard error report view with backtraces, breadcrumbs, and HTTP context. The product is in 1.x and the feature surface is conservative — the team has explicitly framed it as “error tracking, not observability,” which mirrors the position urgentry takes.

urgentry covers the same baseline plus the 218 Sentry REST API operations our compatibility matrix tracks, which matters for teams that automate releases, source-map uploads, and issue queries through CI/CD. If you use sentry-cli in your release pipeline, the same commands work against urgentry. The audit at /sentry-alternative/ lists every operation. Telebugs does not advertise REST API coverage at the same level; its primary surface is ingest plus UI.

Neither product ships session replay today. Session replay is the most-requested feature gap in this category, and the honest answer from both projects is that it’s a separate problem with a separate storage profile. The bridging pattern — run OpenReplay or PostHog Replay alongside, link by session ID — is documented in our session replay guide and applies regardless of which error tracker sits behind it.

Where the AI-agent angle fits

One trend showing up across X this month: operators want their AI coding agent to read from their error tracker. A read-side MCP server in front of the tracker turns triage into a Claude or Cursor session against real data, with no write authority and a project-scoped token. We covered the pattern at /guides/ai-agents/read-side-mcp-error-triage/; the prerequisite is a query API the MCP server can authenticate against.

urgentry exposes the Sentry-compatible REST API for this purpose; a read-side MCP in front of it can list issues, fetch event detail, fetch breadcrumbs, and search by tag using the same operations sentry-cli uses. Telebugs does not currently document an equivalent read API surface. If the agent-triage workflow is part of your plan, urgentry has the read-side hooks already in place. If you are using a human-driven workflow only, this difference doesn’t matter.

Three teams each one fits

Telebugs fits teams that:

• Want a paid, vendor-supported, packaged product and treat the $299.99 line item as cheaper than reading source.
• Already run Rails apps and Docker containers; the Telebugs deployment looks like every other service they operate.
• Care about email + push notifications and a clean issue UI and do not need a deep REST API or agent integration today.

urgentry fits teams that:

• Prefer a single static binary and a systemd unit over a container stack with a Ruby runtime to upgrade.
• Want source visibility and a permissive long-term license trajectory (FSL today, Apache 2.0 in two years).
• Either run an existing Sentry-cli release pipeline, plan to plug an AI agent into the tracker, or want the OTLP ingest path alongside the Sentry SDK envelope.

Neither product is “better” in the abstract. The same team that picks Telebugs for one project might pick urgentry for another, and the same instinct — stop paying Sentry, run something small on a small server — sits behind both choices.

The honest gaps

Telebugs is brand new. As of the public announcement on June 1, 2026, the user base is small and the operational track record is short. Buying a one-time license for a product without a long upgrade history is a bet on the maintainer. The Telebugs team has a track record from prior Rails projects, but the project itself is freshly launched.

urgentry is younger than Sentry self-hosted or GlitchTip and the session replay product surface remains a P2. The compatibility matrix is published as a source-scanned audit precisely so teams can verify coverage themselves rather than trust the vendor; we keep it honest because the alternative — quiet gaps the team discovers post-cutover — is worse for everyone.

Either way: run the switch proof before any team meeting about replacing Sentry. Thirty minutes, one DSN, one real event landing in the new backend. The decision becomes mechanical after that.

Frequently asked questions