GlitchTip vs. Sentry vs. Bugsink

Bugsink vs. GlitchTip vs. Sentry
Three options for error tracking: Bugsink, GlitchTip, and Sentry.

If you’re looking to self-host error tracking in 2025, three tools come up repeatedly: Sentry, GlitchTip, and Bugsink.

They all support the same SDKs. They all capture exceptions and group them into issues. But the architecture, goals, and maintenance burden vary quite a bit.

This article compares them based on focus, installation, runtime behavior, and long-term usability. Written by the author of Bugsink, but based on actual use of all three tools, including in production.

What Each Tool Tries to Be

Sentry

Sentry is not just an error tracker. It’s a full observability platform with APM, session replay, metrics, and performance monitoring. The core idea is: send it everything — traces, spans, errors, sessions — and make sense of it later.

It’s a powerful SaaS product. The self-hosted version exists, but isn’t recommended. You’ll need Kafka, Redis, ClickHouse, and more, plus a good chunk of RAM.

GlitchTip

GlitchTip keeps close to the original Sentry model: use the same SDKs, similar architecture, and permissive licensing. It’s simpler than full Sentry, but still includes Redis, PostgreSQL, Celery, and a frontend/backend split.

It also tries to do a bit more: basic uptime, performance monitoring, and alerting, though some of these features are no longer maintained.

Bugsink

Bugsink is not a clone of Sentry or a fork of GlitchTip. It’s a fresh implementation, focused on doing one job well: tell you when something broke, and why.

It deliberately skips dashboards, traces, and uptime checks. It doesn’t promise “observability” — just reliable, self-hosted error tracking with minimal infrastructure.

Error Reports and UI

All three tools show stack traces. The difference is what else they try to show, and how much they get in the way.

Sentry

Sentry’s UI is dense. Errors come with graphs, performance tabs, breadcrumb timelines, and lots of surrounding metadata. If you’re using the full APM feature set, that’s useful. If you just want to see the exception and fix it, it’s a lot of extra clicks.

Also: for environments that don’t trigger a lot of errors, the UI can feel overwhelming. The sheer amount of toggles, filters, and options can make it hard to find the actual error details.

Error-view in Sentry
Error-view in Sentry

GlitchTip

GlitchTip displays the exception with a layered layout. Information like runtime version, tags, and exception details appear before the stacktrace itself. Source code lines are collapsed by default, and much of the screen is taken up by UI elements that aren’t directly related to the error. The essential debugging data is there — just not front and center.

Chained Exception in Bugsink
Example of a chained exception in GlitchTip

Bugsink

Bugsink shows the entire exception chain, with source lines visible, and local variables shown inline when possible. No breadcrumbs, no performance tabs, no popups. Just a structured stacktrace that’s easy to scan and act on.

Chained Exception in Bugsink
Example of a chained exception in Bugsink

Self-hosted Setup

Sentry

Sentry is marketed primarily as a SaaS product. If sending your data to their servers is acceptable, and you’re OK to pay for it, that’s the easiest way to get started.

The self-hosted version is available, but it’s not easy to set up or maintain. You’ll need to run a stack that includes:

  • Kafka
  • Redis
  • ClickHouse
  • Snuba
  • More than 9 containers

The documented baseline is 16GB RAM, and that’s just to get started. Upgrades are manual. Scaling guidance is not provided. Read more in “why I gave up on self-hosted Sentry”.

GlitchTip

GlitchTip is easier than Sentry, but still involves multiple services:

  • PostgreSQL
  • Redis
  • Celery workers
  • Frontend/backend split

You’ll need to understand how these parts fit together and keep them in sync. It’s doable — but if you’re expecting something you can just drop into a container and forget about, GlitchTip may need more care than you want to give it.

Bugsink

Bugsink runs as a single container. No Redis, no queue, no separate frontend. You can start with SQLite, or switch to PostgreSQL/MySQL for production.

The simplest install is a single Docker command, and should take under a minute. But other options are available if you need them.

docker pull bugsink/bugsink:latest

docker run \
  -e SECRET_KEY=8pA8HvrILcVscS4ojZexI9eElkbhx6d8A03uyLpTlp577vQLFx \
  -e CREATE_SUPERUSER=admin:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Upgrades are migrations and restart. That’s it.

Scaling and Runtime Behavior

Sentry

Sentry SaaS handles huge volumes. The self-hosted version can too — if you replicate the full setup, monitor it, and tune it yourself. The default install needs 16GB RAM just to start.

GlitchTip

GlitchTip works at moderate volume, but documentation is sparse when it comes to long-term operation. There’s little info about retention, sampling, or what to do when traffic spikes. If you’re expecting real traffic growth, you’ll be figuring things out on your own.

Bugsink

Bugsink is built to run lean. It can handle 1.5 million events/day on a €5 VPS (2 vCPUs, 4GB RAM). There’s no queueing layer, no Redis, and no manual cleanup required.

It uses smart retention to automatically keep representative samples when volume is high — so you don’t have to worry about disk usage or manually trimming events.

Features and Integrations

SDKs

All three tools use Sentry-compatible SDKs. That means you can switch tools by just updating the DSN. Bugsink and GlitchTip both ignore unsupported features like performance monitoring or replays.

Bugsink supports the Sentry CLI, including source map uploads.

Search

  • Sentry supports advanced search with structured filters and tag queries. It’s flexible, though aimed more at users comfortable with its full observability model.

  • GlitchTip supports basic tag filtering using tag:value, as noted in an early release note. Beyond that, its search capabilities are unclear. There’s no comprehensive documentation, and it’s hard to tell what kinds of queries are actually supported.

  • Bugsink supports simple key:value queries, with fast tag-based search in the database. It’s documented, predictable, and works.

Alerts

  • Sentry: configurable rules, team-based notifications, often tied to performance metrics.
  • GlitchTip: email/webhook alerts, but behavior can be confusing. Issue #260 is one example — muting one project silenced all alerts.
  • Bugsink: per-project email alerts for new issues, regressions, and repeat errors. Designed to be simple and reliable.

License

  • Sentry: Functional Source License: don’t use it as a service, or repackage it. You can self-host, but you can’t offer it as a service to others.

  • GlitchTip: MIT — do what you want.

  • Bugsink: Polyform Shield — don’t compete with Bugsink, but you can self-host and use it as a service. The license is designed to allow self-hosting without restrictions, while preventing direct competition.

Who Should Use What

If you want a full APM platform — traces, dashboards, replays — and plan to use the hosted version, Sentry is the most complete option.

If you need something fully open source, and are comfortable managing Redis, workers, and a frontend stack, GlitchTip is a fair middle ground. But be ready to take over if maintenance slows down.

If you want fast, minimal error tracking that just works, even under heavy traffic, Bugsink is built for that. No queues, no dashboards, no hidden moving parts. Just the errors, with context.

Finally, if you want to compare either of the two others against Bugsink, check out these articles: