Find out a client integration is failing before they tell you.

A partner's integration starts failing. You find out when they email you, which is usually a day or two after it started and always after they have formed an opinion about your reliability.

Generic error tracking tells you something threw. It does not tell you whose call it was, or which version of the endpoint they asked for — which is the part that determines whether this is a bug in your service or a client still on v1 doing something v1 allowed.

Errors are grouped by a fingerprint computed from a normalized stacktrace, not the raw blob. Line numbers, application version prefixes, and frames below a configurable depth are stripped before hashing.

Without that, the same logical error splits into a new group every time an edit above the throw site shifts a line number, or a new release changes the version prefix — so the thing failing constantly looks like forty rare things instead of one common one.

Because errors arrive on the same pipeline as authorizations and requests, they carry the context those have: which service was calling, which endpoint, which endpoint version. An error becomes a fact about a specific integration rather than a stack trace in a pile.

Probes call an endpoint on a schedule and mark it unhealthy after a threshold of consecutive failures. Spy checks watch the responses your services are already returning and flag an endpoint whose failure rate crosses a line over a window — no synthetic traffic, no extra load.

Both feed the same state machine, so an endpoint going unhealthy or recovering is one event regardless of which noticed it.

Unhealthy, recovered, and error events route to Slack, Teams, or email by rule. Notifications from a single deploy are batched into one digest rather than twenty messages, which is the difference between an alerting channel people read and one they mute.