Watchtower — self-hosted error & performance monitoring

01 / grouping

Ten thousand errors, one issue.

Every exception is fingerprinted by its type, message shape and the frames that matter — so a storm of the same fault collapses into a single row with a count, not a wall of noise.

Stable fingerprints survive line-number churn
Resolve one, and a regression re-opens it automatically
Mute the ones you'll never fix

checkout-api · unresolvedgrouping

02 / releases

Every release, graded.

Watchtower knows which deploy each event belongs to. The moment a version ships, you see what it introduced, what it regressed, and what it finally fixed.

Deploy markers on every occurrence graph
Adoption: how much traffic is on the new build
One glance tells you whether to roll back

checkout-api · releaseslive

03 / context

From alert to the exact frame.

The stack trace lands with your code highlighted, the breadcrumb trail that led there, the request and the user. Not "something failed" — this line, this input, this release.

Full breadcrumbs: routes, queries, clicks, logs
Local variables on the failing frame
Linked straight to Jira or Linear, status synced both ways

issue #4821 · breadcrumbstrace

It runs next to your app

Your errors never leave your box.

One container, one database. Point your SDK or your OpenTelemetry exporter at it and you're collecting. No per-event pricing, no seat math, no third party holding your stack traces.

Your data

Events, traces and logs sit in a Postgres you control, with retention you set.

Drop-in SDKs

Sentry-compatible clients and OTLP ingest — most apps switch by changing one URL.

Deploys next to it

Ships as a single image. Built for a small server sitting beside the app it watches.

Know what broke. Down to the line.

NoMethodError: undefined method `total' for nil