Operational claims should point to a real check.

Certus does not publish an unmeasured “all systems operational” banner here, and it does not yet publish a public incident feed. Saying so is more useful than a green light no check stands behind.

A revision reaches a Certus deployment only after its recorded gates pass: dependency and boundary rules, static typing, the engine and fixture suites, a typecheck, lint and production build of both front ends, and a build of every deployable image. The deploy step then runs post-deploy smoke probes against the released containers.

Those records live in the private deployment pipeline. A passing gate says that one exact revision met those checks at the moment it shipped; it does not promise that a later incident has not occurred.

Inside a deployment, GET /healthz reports that the API process is serving requests. The public webhook ingress exposes GET /_ingress/health, which reports that the proxy itself is reachable without forwarding a request to the engine.

The engine health route is intentionally unavailable on the public webhook ingress. Deployment operators run both probes from their authorized network and treat them as separate signals.

A liveness response proves that one process or proxy answered at that moment. It does not prove database readiness, model-provider availability, sandbox capacity, or the outcome of a customer run. Those facts remain visible through their own typed failures and deployment telemetry.

Enterprise customers should use their named support channel for live incident coordination. Evaluation teams can email sales with the affected deployment and approximate time; do not include credentials or repository content.