Liveness: GET /health
Public, unauthenticated, and cheap. It proves the API process is answering.
200
Auth stack: GET /monitor/auth
This one fails when a merchant could not sign in — the thing actually worth being woken for. It exercises the same dependencies, in the same order, that authenticating a real request does:
Redis is reported but not fatal by design: the API deliberately fails open on it, so sign-in survives a cache outage. Paging someone for that would be a false alarm.
Authentication
The probe is gated by a shared secret sent in theX-Monitor-Key header. A header rather than a query parameter on purpose — query strings end up in access logs, proxy logs and Referer headers, so a URL-borne secret leaks by design.
A missing or wrong key returns 404, not 401, so an unauthenticated scanner cannot tell the route exists.
200
503, status becomes AUTH_DEGRADED, and the failing check carries a detail string:
503
Configuring your monitor
The response is shaped so the two most common alert rules both work, and either one alone is sufficient:1
Add the header
Set a custom request header
X-Monitor-Key to your key. Most monitors (BetterStack, Checkly, Pingdom, Uptime Robot) support custom headers on HTTP checks.2
Alert on status code
Rule: HTTP status other than
200. A degraded auth stack returns 503; a wrong key returns 404, which also alerts — that is deliberate, since a monitor with a stale key is not monitoring anything.3
Or alert on keyword
Rule: body does not contain
AUTH_OK. The keyword lives in its own field so a future change to the response shape cannot silently remove it.The probe is side-effect free: no session is created, no row is written, no email is sent, and the database check returns a count rather than any record. Polling it every 30–60 seconds is fine.