Bugsink vs. GlitchTip

Bugsink vs. GlitchTip
Side-by-side comparison of Bugsink and GlitchTip

If you’re self-hosting error tracking, you’ll likely run into two options that are actually maintained and built for self-hosting: GlitchTip and Bugsink.

Both use Sentry-compatible SDKs. But beyond that, they’re somewhat different. If you’ve already realized that self-hosting Sentry isn’t really feasible, this comparison should help you choose what to run instead.

Full disclosure, if the big heading didn’t make it obvious: this article was written by the creator of Bugsink. I’ve run GlitchTip in production, and came out thinking that there’s room for improvement. Bugsink is the result of that experience.

Origins and Philosophy

GlitchTip was created in 2020, shortly after Sentry moved away from open source. Its goal was to preserve the ability to self-host a Sentry-like tool under a permissive license. Basically: a direct response to Sentry’s decision to relicense their product.

Bugsink came out of the need for something that would stay out of the way. Whatever the license, self-hosting Sentry was infeasible for me, and I wanted a tool that would be easy to install and maintain. I ran GlitchTip for a while too, but it needed just enough care to become a chore while not being polished enough to be worth the effort. So I built Bugsink. Not a fork, not a rewrite, just a clean system designed for reliable, low-maintenance self-hosting.

Installation and Maintenance

Bugsink is a single Django app. You can run it as a container with SQLite, or use MySQL/PostgreSQL for production. Single-container by default, no Redis, no background queue.

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=qhSN4lADFkfssEvnnHJ8aNQbBtDXqCMjq08TTrAARI3XvVRRRG \
  -e CREATE_SUPERUSER=admin:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Likewise, and upgrades are dead-simple: just apply migrations and restart.

GlitchTip installation

GlitchTip has more moving parts:

  • PostgreSQL
  • Redis
  • Celery as a background worker
  • Frontend/backend split

Deploying GlitchTip means understanding how these components fit together, and keeping them in sync. That’s fine if you’ve got ops support, but for smaller setups it adds friction. Even after setup, staying up-to-date means tracking multiple versions and occasionally rebuilding the frontend. Bugsink was designed to avoid that kind of upkeep.

Scalability and Reliability

Bugsink was designed with one goal: stay fast and stable under high error volume without becoming a maintenance burden. It keeps ingestion lightweight and avoids expensive processing paths that can bottleneck the system. From payload parsing to grouping logic, every step is tuned for throughput. The result is a system that can comfortably handle 1.5 million events per day on a €5 VPS.

It also includes smart retention: full event data is kept until volume gets high, after which representative samples are retained. Grouping and summaries stay accurate, and no separate queues or cleanup jobs are required.

GlitchTip probably works well at moderate scale, but its behavior under sustained heavy load is largely undocumented. There are no documented mechanisms for sampling, throttling, or retention, and no detailed guidance on what to monitor or when to intervene. If you’re self-hosting and growth is expected, this leaves you guessing about where the limits are.

Stacktrace Presentation and UI

Different tools make different choices about what matters most in an error report. Here’s the same error, shown in Bugsink and GlitchTip.

The screenshots below are unedited, taken from a default local install.

Bugsink

Chained Exception in Bugsink
Example of a chained exception in Bugsink

Bugsink shows the full exception chain in a structured way, with source lines visible by default and controls to expand or collapse frames as needed. There’s no visual clutter – just a clear view of what happened and where. If local variables or function arguments were available, they’d appear inline. The focus is always on making the stacktrace easy to read and act on.

GlitchTip

Here’s how the same error looks in GlitchTip:

Chained Exception in Bugsink
Example of a chained exception in GlitchTip

GlitchTip presents the same exception in a more layered interface. Metadata like runtime version, environment tags, and exception mechanisms appear above the stacktrace. Source lines are hidden by default, and much of the visible space is taken up by surrounding UI elements that aren’t directly part of the stacktrace. The result is a layout where the core debugging information is available – but not immediately prominent.

Features

Both tools support Sentry-compatible SDKs, so you can use the same libraries to send errors. But there are some differences in how they handle the data once it arrives.

Bugsink includes a fast, tag-based search system that lets you filter by message content, exception type, and any attached metadata—like environment, release, browser, or OS. Queries use a simple key-value syntax (environment:production) and are executed directly in the database. For details, see the blog-post on Search.

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.

Alerting

Bugsink provides email alerts for new issues, regressions, and umute-after-x. Notifications are configurable at the user and project level, with behavior kept simple and predictable. For more, see /docs/alerts/.

GlitchTip supports email and webhook alerts, with per-project configuration. But the team model affects who gets notified, and the rules can be hard to reason about. I originally reported issue #260 after discovering that muting alerts in one project disabled them in all projects. The fact that that issue took so long to resolve was actually one of the original reasons for building Bugsink: A bug tracker that doesn’t reliably tell you something broke isn’t doing its job.

Performance Monitoring and Uptime

GlitchTip supports basic performance and uptime tracking. You can send transactions and spans using Sentry SDKs, and set up heartbeat monitors for uptime. But the tracing interface is minimal, and by the project’s own admission, not under active development. The maintainers have said they may remove it unless someone else takes it on.

Bugsink deliberately doesn’t support performance or uptime features. It’s a focused error tracker, not an APM.

Non-Technical: Licensing and Documentation

Bugsink is source-available under the Polyform Shield License. You can run it in production, modify it, and contribute code. The only restriction is that you can’t offer it as a competing service.

GlitchTip uses the permissive MIT license, allowing full modification, hosting, and redistribution.

Documentation

Bugsink includes full documentation: installation, configuration, debugging workflows, search, and internals. It’s written for developers who might return to it six months later and still need to understand what’s going on.

GlitchTip provides basic setup and deployment instructions, but offers less depth on internals and long-term operation.

Target Audiences

For solo developers:

  • Bugsink: fast to install, minimal upkeep, and designed to stay out of the way.
  • GlitchTip: setup takes more time, and staying up-to-date requires more coordination.

For larger teams:

  • Bugsink: built for stability and scale without ops overhead—useful if you’re replacing hosted Sentry.
  • GlitchTip: offers additional integrations like uptime and performance, but they may require closer management.

Final Thoughts

This comparison is written by the creator of Bugsink. I’ve run GlitchTip in production: configured the stack, filed issues, and dealt with things like alerts not working as expected. That experience shaped how Bugsink was built.

It’s not a fork or a clone. It’s a fresh take, based on what I wished had existed: reliable, transparent, low-maintenance error tracking. Something you can install and trust to work, without digging through layers of UI or worrying about what just got dropped.

If that’s what you’re after, try Bugsink. If GlitchTip fits your setup better, it’s still worth a close look – especially around alerting and search, where details matter.