Health
Service health monitoring. A public endpoint that checks the SpeyBooks subsystems and returns per-service status with latency measurements.
Authentication
Public, no authentication required.
Liveness versus readiness
The api sub-check is liveness: if this endpoint returns at all, the process is up. The database, email, and auth sub-checks are readiness, they probe live dependencies. So a 200 attests that the process is live and no dependency is in full outage; a dependency may still be degraded, which the body reports.
Status Model
Each service reports one of three states:
- operational: responding within acceptable latency
- degraded: responding but slow, or returning unexpected status codes
- outage: unreachable or timed out
The overall status field is the worst of all service statuses:
any outage makes the overall outage; any degraded with no outage
makes the overall degraded.
HTTP Status Code
200: operational or degraded (the service is functioning)503: outage (at least one dependency is down)
Uptime monitors should alert on 503; for degraded detection, parse the body and read the per-service statuses, since degraded is still a 200.
Subsystem Checks
| Service | Method | Timeout | Degraded threshold |
|---|---|---|---|
| API | implicit (the endpoint responds) | n/a | n/a |
| Database | SELECT 1 connectivity query |
3 seconds | over 1000ms |
| email-provider reachability call | 5 seconds | timeout without error | |
| Auth | login-endpoint probe | 3 seconds | unexpected HTTP status |
The auth check sends throwaway credentials to the login endpoint and treats a 400 (validation) or 401 (invalid credentials) as proof the auth pipeline is processing requests; a 429 (rate limited) is also treated as operational.