loghq vs GlitchTip
GlitchTip is the other open-source name here, and a genuinely good one. It reimplements a Sentry-compatible API, so you can point existing Sentry SDKs straight at it, which is a real advantage if you are migrating off Sentry. loghq is a different bet: a Stacks-native, Postgres-only app with its own SDK and a tighter, more opinionated triage flow. If SDK compatibility is your priority, GlitchTip is hard to beat; if you want a self-contained app that matches this stack, loghq fits.
loghq and GlitchTip, side by side
Where GlitchTip leads: it speaks the Sentry API, so existing Sentry SDKs and DSNs work with almost no change. For a migration off Sentry, that compatibility is a strong reason to choose it.
Why teams pick loghq
Stacks-native
loghq is built on the same stack as your app, with a single Postgres dependency and no Django runtime to operate alongside it.
Opinionated triage
loghq leans into a tight new-and-spiking triage flow rather than mirroring the Sentry UI, which some teams find simpler to live in day to day.
One SDK, one app
loghq ships its own SDK designed for this platform. If you are not tied to Sentry SDK compatibility, that keeps the whole path first-party.
Honestly, they overlap
Both are open source and self-hostable, so this is less switch and more fit. GlitchTip wins on Sentry compatibility; loghq wins if you want a self-contained, Stacks-native app. Either keeps your data yours.
What loghq is
Open-source error and crash tracking you can run on your own Postgres, or use on a hosted tier. Automatic capture, fingerprint grouping, source-mapped traces, releases, and alerts, without the rest of an observability suite.