urgentry vs GlitchTip: two Sentry-SDK-compatible paths to self-host.

Why this comparison exists

GlitchTip predates the current crop of clean-room Sentry-compatible servers by a few years. It has been the answer to “Sentry self-host is too much” since 2019, and a real community has built around it. That makes it the natural baseline for anyone evaluating a smaller error tracker.

urgentry takes a different bet. Single binary. No queue. No worker process. OTLP traces and logs land in the same place errors do. The trade-offs are different from GlitchTip’s, and a fair comparison has to name them.

I am writing this from the urgentry side, and the bias is what you would expect. The check on that bias is the “when to pick GlitchTip” section near the end, which is not pro forma.

What “Sentry-SDK-compatible” means in both projects

Both projects accept events from the official Sentry SDKs without code changes. The contract is the DSN: point your SDK at https://<key>@your-host/<project-id>, and events flow.

The shared surface includes errors, breadcrumbs, releases, environments, user context, and the standard envelope format used by modern Sentry SDKs. Both projects document the SDKs they target. Both projects accept the legacy /api/<id>/store/ path for older SDK versions, and both accept the modern /api/<id>/envelope/ path.

They diverge on what happens after ingest. GlitchTip uses Celery to push events through Redis to a worker process, then stores them in Postgres. urgentry handles ingest, grouping, and storage in a single Go process, with SQLite as the default database and Postgres as an option for teams that want it.

The capability matrix

One table, honest where it can be, blank where neither project should claim a number.

Where GlitchTip is ahead

This is the section that determines whether the comparison is honest.

Years of production deployments

GlitchTip has been running in production environments since 2019. That is a long tail of bug reports, edge cases, and operator workarounds that any new project has to grow into. If your team values “it is boring, and we know its failure modes,” GlitchTip wins this row decisively.

A familiar operational shape

GlitchTip is Django, Celery, Redis, and Postgres. Almost every backend team has run that combination at some point. The runbook for “why is the worker behind?” or “why did Postgres connections spike?” already exists in your head. urgentry asks you to learn a new shape, even if that shape is simpler.

MIT license

GlitchTip is MIT-licensed. There is no time delay, no transition clause, and no commercial-use restriction to read. For organizations whose legal team has a flat “MIT or Apache-2.0 only, no exceptions” rule, GlitchTip clears that gate immediately. urgentry’s FSL-1.1-Apache-2.0 license is permissive in most respects but does include a two-year transition window. That is a fair concern to raise.

A hosted option from the project itself

GlitchTip runs app.glitchtip.com as a paid hosted service. If you want the Sentry-compatible SDK experience without operating anything, you can pay GlitchTip directly. urgentry does not offer that today. Some teams care; others do not.

Where urgentry is ahead

The compensating rows are real but narrower than they sound.

Single binary, no queue

urgentry is one process. Ingest, grouping, storage, alerting, and the UI all live in the same Go binary. There is no Celery worker to fall behind, no Redis to monitor, and no broker connection to debug. For a 1 to 4 GB VPS, this is the difference between “it runs” and “it fits, with margin.”

Memory footprint at small scale

urgentry settles around 52 MB resident memory under steady ingest at 400 events per second on the reference benchmark hardware. GlitchTip’s own deployment docs suggest planning for roughly 1 GB across the web process, worker, Postgres, and Redis combined, and operator reports on its issue tracker push that higher under real load. Neither project competes with the other on this axis; they are not aiming at the same hardware.

Native OTLP for traces and logs

urgentry accepts OpenTelemetry traces and logs over OTLP/HTTP directly, in the same binary that takes errors. GlitchTip is errors-first and does not advertise OTLP ingest at the time of writing. If your stack already exports OTLP from Go, Python, or Node services, that is a meaningful difference in setup time.

SQLite as a real option

urgentry runs against SQLite by default and against Postgres if you ask for it. GlitchTip requires Postgres. SQLite is not always the right choice, but for a single-tenant deployment with a few engineers and modest event volume, removing the database process is a genuine simplification.

The deployment shape, side by side

The fastest way to feel the difference is to set both up.

GlitchTip, from the official documentation:

wget https://glitchtip.com/docker-compose.yml
# edit the SECRET_KEY, DATABASE_URL, EMAIL_URL, GLITCHTIP_DOMAIN
docker compose up -d
# four to five services come up: web, worker, postgres, redis, optional migrate

urgentry, from its own:

curl -fsSL https://urgentry.io/install.sh | sh
urgentry --config /etc/urgentry/config.yaml
# one process; SQLite database file on disk; no queue

Both are short. The honest comparison is what comes after “up.” With GlitchTip, you now operate Postgres and Redis. With urgentry, you operate one binary and a file on disk. Neither is the wrong answer; they are different answers.

The license question

GlitchTip is MIT. That is the most permissive widely-used open-source license, and there is nothing more to say about it.

urgentry is FSL-1.1-Apache-2.0. Functional Source License 1.1 prevents a third party from offering urgentry as a competing hosted service for two years from each release; after the two-year window, every release converts to plain Apache-2.0. The same license is what Sentry itself uses for its source-available distribution. For internal commercial use, FSL-1.1 has no practical effect that MIT does not also have. For organizations that want a perfectly flat “OSI-approved licenses only” rule, FSL-1.1 is not OSI-approved yet, and that may matter for legal review.

The honest framing: both licenses let you run the software for your own use, modify it, and ship it inside your products. The differences matter at the edges, not in the middle.

When to pick GlitchTip

The cases where GlitchTip is the right answer, and where I would tell a friend to pick it:

• Your stack is already Django, Postgres, and Redis. Adding another service in that shape costs almost nothing.
• You want the project to host it for you, and you would rather pay GlitchTip than self-operate.
• Your legal team has a strict MIT-or-Apache-2.0 rule with no exceptions.
• You need a tracker that has been in production since 2019 and has the bug-tracker depth that comes with that.
• You do not need OTLP traces or logs from the same service; you have a separate observability stack for those.

If three or more of those apply, urgentry is the wrong choice for you, and that is fine.

When to pick urgentry

The cases where urgentry is the better answer:

• You want to run on a 1 to 4 GB VPS without margin anxiety.
• You are tired of Compose stacks and want one binary in /usr/local/bin.
• You already export OTLP and want errors, traces, and logs in the same place.
• You are building from scratch and the operational toolkit is not yet decided.
• You want the option to start on SQLite and move to Postgres later, on your schedule.

What this comparison is not

A few things this article is deliberately not doing.

It is not a UI comparison. Both projects have functional UIs; the experience differs in details that change month to month. If the UI is your decision driver, run both for an hour and decide for yourself.

It is not a quality judgment on GlitchTip. The project is well-built, actively maintained, and run by people who care. The reason urgentry exists is not a complaint about GlitchTip; it is a different bet about what shape the next generation of self-hosted error trackers should take.

It is not a recommendation that you migrate from GlitchTip to urgentry. If GlitchTip is working for your team, leave it. Migrating between tools that solve the same problem is rarely worth the disruption unless the constraints that drove the original choice have moved.

What to do next

If you have not yet picked an error tracker, run both for a week against the same DSN-swap proof. Send a real event from your real code. Trigger a real alert. Look at the resulting issue page. Whichever one your team reaches for the second time is the right answer.

If you are already on GlitchTip and reading this because urgentry came up in a thread somewhere: there is no urgency to move. The deployment-shape advantages are real, but they pay off most at the start of an installation, not after you have already absorbed the operational cost.