Platform Health & Public Status: Green Means Something
How readiness checks, the admin health cockpit, job runs and public status keep incidents from becoming folklore.
Health checks are not glamorous. That is their charm. They tell platform staff whether the app, database, storage, mail, cron, webhooks, public API, billing and other components are behaving well enough for normal work.
/api/health
The technical health endpoint returns app readiness with component checks, latency and sanitized status. It is built for uptime monitoring and deploy smoke checks, not for leaking database details to the internet.
Platform cockpit
/admin/platform/health gives platform staff a fuller incident view: component status, release readiness, support context and recent job outcomes. Cron routes and background jobs write bounded job-run records so the platform can answer whether a scheduled task ran, failed, blocked or quietly took a nap.
Public status
/api/status/public exposes a sanitized component feed for a status page or external monitor. It can say that file storage or scheduled jobs are degraded without revealing tenant names, payloads, secrets or stack traces. Transparency is good; oversharing is still oversharing.
Why it matters
When something is wrong, support needs a shared source of truth. Health turns "is it just me?" into "storage is degraded, uploads are affected, everything else is fine." That sentence saves a surprising amount of oxygen.