Join our community: https://t.me/+DOylgFv1jyJlNzM0
Why this matters
A separate issue already tracks the hardcoded lag threshold in health.routes.ts. This issue is about the response shape: if both a database outage and a lagging indexer report the same generic unhealthy status with no reason or component field, an on-call engineer looking at monitoring dashboards can't tell at a glance which subsystem needs attention without digging into logs.
Acceptance criteria
Files to touch
backend/src/routes/health.routes.ts
Out of scope
- Changing the lag threshold value (tracked separately)
- Adding a full status-page integration
Why this matters
A separate issue already tracks the hardcoded lag threshold in
health.routes.ts. This issue is about the response shape: if both a database outage and a lagging indexer report the same genericunhealthystatus with noreasonorcomponentfield, an on-call engineer looking at monitoring dashboards can't tell at a glance which subsystem needs attention without digging into logs.Acceptance criteria
checksobject to the health response breaking down individual subsystem status (database, redis, indexer lag, soroban RPC)statusfield for simple uptime monitors that only check one fielddocs/apiOpenAPI/Postman references to reflect the new shapeFiles to touch
backend/src/routes/health.routes.tsOut of scope