Homelab 17: your errors find you, with GlitchTip instead of Sentry

Level IntermediateEstimated time 1 hRead first Homelab 1: Proxmox, the base under every serviceA word you don't know? Glossary

When a service crashes at 3 a.m., you find out days later, by chance, in a log. An error tracker turns that around: every service sends its errors to one place, grouped so that a thousand identical crashes are one line, with when it started and when it last happened. Sentry is the reference; self-hosted, it needs a dozen containers and 16 GB of RAM. GlitchTip speaks the same protocol with three.

Each service reports its own errors to the tracker with the same SDK as Sentry; a script can post one with a single curl. Errors are grouped into issues, so a thousand identical crashes are one line, with the first and last time they happened.

A bit of history

Sentry began in 2008 as a small plugin for Django that collected errors from production code; it grew into the reference of error tracking, and its licence later changed. GlitchTip, started in 2020, is an open-source alternative that speaks Sentry's protocol, so the official Sentry libraries send their errors to it without any change in your code.

1. Run it

GlitchTip runs as a web container, PostgreSQL and Valkey (or Redis). Follow the official Docker Compose setup, pin the versions, and close sign-ups once your account exists. Two settings saved us from a silent failure:

GLITCHTIP_EMBED_WORKER=true on the web container if you do not run a separate worker. Without a worker, events are accepted and never processed.
a one-shot migrate service in the compose file: the database is not migrated at start by itself.

Keep it on your home network or your private network (Homelab 6): your errors describe your weak points.

2. Connect your services

Create one project per service; each gets its own DSN, the address its SDK reports to. Any Sentry SDK works: set the DSN and initialise it at start. A shell script without SDK can report with one request to the project's store endpoint, for example when a nightly job fails.

Traps

Prove it end to end the day you set it up: send one test event from each service and see it arrive as an issue. A tracker that silently drops events is worse than none, because you believe nobody crashed.

Keep DSNs out of your repositories: put them in each service's environment. A DSN lets anyone flood your tracker.

Sources

Found this useful? Tell us what to measure next.