Skip to main content

Platform Health

Platform Health rolls API errors, chain connectivity, workflow completion and data freshness into one verdict for platform admins and Owners.
Four independent panels roll up into one verdict, and the worst panel wins.Four quiet input cards sit in a row, each showing its own current verdict. Platform API reads operational, Transactions reads operational, Workflows reads operational, and Data freshness reads degraded. Arrows from each converge into one focal card labelled Rollup verdict, worst of four panels wins. Below the focal card, four small outcome chips read outage, degraded, operational, and no data. An accent arrow from the focal card points to the degraded chip, showing that the one degraded panel among three otherwise healthy ones is enough to make the overall verdict degraded.Four independent panels roll up into one verdict, and the worst panel wins.The same figure as the desktop variant, drawn portrait for phone widths. Four quiet input cards each show their own current verdict. Platform API reads operational, Transactions reads operational, Workflows reads operational, and Data freshness reads degraded. The cards stack vertically and each send an arrow down into one focal card labelled Rollup verdict, worst of four panels wins. Below the focal card, four outcome chips read outage, degraded, operational, and no data in a two-by-two grid. An accent arrow from the focal card points to the degraded chip, showing that the one degraded panel among three otherwise healthy ones is enough to make the overall verdict degraded.

The Platform status page rolls up four independent panels into one verdict, and the worst verdict among them wins, never an average.

  • Every panel resolves to one of four verdicts: outage, degraded, operational or no_data, which means there is no signal to judge.

  • Only a platform admin or the organisation's Owner can open the Platform status page. On a shared deployment, every Owner sees request totals and error rates summed across all organisations, never another organisation's requests.

  • A rollup takes the worst verdict among independent panels, and the best verdict within a redundant provider pool. One failed upstream does not fail the chain while any other in the pool still answers.

One verdict for the whole platform

Platform Health is the condition the platform reports about itself, and the Console's Platform status page shows it as one verdict. A platform admin or an organisation's Owner reads there whether the platform is healthy now, without reconciling separate charts. A monitored signal that crosses its condition reads as outage or degraded. A chain that is reindexing after a restart or backfill reads as operational. Rebuilding state is the indexer working as designed, so a restart does not turn the page red.

Data freshness, Transactions and Platform API read the whole deployment, because the indexer, the chains and the API serve every organisation. Workflows counts only your organisation's background work, so two organisations on one deployment can see different headers.

Reading the Platform status page

The page leads with four core panels, Data freshness, Transactions, Platform API and Workflows, which arrive together from one read. A slow source holds all four, and a failed Data freshness, Transactions or Platform API source fails all four. A failed workflow source leaves only Workflows at no_data. Webhooks, Email, FIX sessions, Batch jobs and Scheduled jobs load on their own, and raise the header only while degraded or in an outage.

The page also shows the same rollup over recent days, hour by hour, so a dip that already recovered stays visible. Each day is judged on the whole day's evidence, then each hour on its own evidence, capped at its day. An hour never reads worse than its day, so a short outage colours only the hours it lasted. The history covers full UTC days only. The day in progress is left out because not every telemetry source publishes a partial day at the same pace.

Panel rollups and the two probes underneath

Panel rollups follow two rules, depending on what they aggregate. Independent panels roll up to the worst verdict among them, because one degraded panel is a real problem however healthy the others are. Redundant providers, such as the pool of upstream RPC endpoints behind one chain, roll up to the best verdict. A chain stays operational while any one of its upstreams answers, and the pool degrades only once every upstream in it does.

Two probes sit beneath the Console page, for the team that runs the deployment. Readiness asks whether the process can serve traffic. /readyz checks Postgres, the indexer's own readiness and whether the Workflow Engine is shutting down, and reports ready only when all three agree. It also answers 503 while the process starts or drains. A failed readiness check takes the process out of the load balancer and nothing more.

Liveness asks whether the process is still running at all. It is served on a port of its own. A thread beside the main event loop reads a heartbeat that loop stamps, and reports the process wedged once the stamp is more than thirty seconds old. Kubernetes restarts the pod on that answer, so a seized process is replaced without an operator. The restart does not fix the cause, so read the runbook if it repeats. That dedicated port is the Platform API pod's. The workflow runner and indexer pods answer liveness on the health port their main loop serves. A seized loop there stops answering, and Kubernetes restarts the pod after four failed probes ten seconds apart.

Readiness watches the dependencies. Liveness watches the event loop.Two lanes contrast the two probes. On the left, readiness: three inputs, a Postgres probe, the indexer's own readiness evaluation, and a check for whether the Workflow Engine is shutting down, feed into a focal card labelled merged readiness service. That card produces the outcome 200 ready, or 503 with a specific reason that takes the process out of the load balancer. On the right, liveness, served on a port of its own: the main event loop stamps a heartbeat, and a thread running beside that loop reads the stamp. A stamp older than thirty seconds answers 503 wedged, which Kubernetes answers by restarting the pod. A fresher stamp answers 200. A failing dependency stops traffic reaching the process. Only the process's own loop seizing gets it restarted.Readiness watches the dependencies. Liveness watches the event loop.The same figure as the desktop variant, drawn stacked for phone widths. Two lanes contrast the two probes, readiness on top, liveness below. Readiness fans out from three inputs, a Postgres probe, the indexer's own readiness evaluation, and a check for whether the Workflow Engine is shutting down, into a focal card labelled merged readiness service. That card answers 200 ready, or 503 with a reason that takes the process out of the load balancer. Liveness, served on a port of its own, watches the main event loop's heartbeat: a stamp older than thirty seconds answers 503 wedged, which Kubernetes answers by restarting the pod, while a fresher stamp answers 200. A failing dependency stops traffic reaching the process. Only the process's own loop seizing gets it restarted.

Readiness checks Postgres, the indexer and the Workflow Engine and stops traffic on any failure, while only a stalled process loop restarts the pod.

The readyz and healthz contract

/healthz on the API port returns { status: "ok" } as soon as the port accepts connections, before the application has finished building, and checks no dependency. The startup probe uses it. /readyz keeps answering 503 until the application has finished building. It then fans out concurrently to a Postgres probe, budgeted at eight seconds, and a host probe that reads the merged readiness of the indexer and the Workflow Engine, budgeted at one second. Any one failing returns 503 with the specific reason. Platform API not ready walks through finding which dependency tripped it.

How the Platform API panel judges a day

The Platform API panel judges each day from integer request counts, and the day's request volume decides which rule applies. A 5xx response is a server error and a 4xx response is a client error.

Requests that day
Condition
Verdict
0
no requests at all
no_data
Fewer than 500
50 or more 5xx responses
outage
Fewer than 500
fewer than 50 5xx responses
operational
500 or more
5xx responses are 5% or more of the total
outage
500 or more
5xx responses are 1% or more, or 4xx responses are 50% or more
degraded
500 or more
otherwise
operational

In the history, this table judges the day. Each hour of that day is then judged by the same 5xx and 4xx shares over its own requests, without the volume split, and capped at the day's verdict. A quiet day judged operational shows no degraded or outage hour. On an outage day, only the hours whose own error share meets the outage condition read outage.

Unauthorised and forbidden responses are excluded from the 4xx count, because an authentication failure describes the caller, not the platform. A flood of failed sign-ins therefore does not move this panel. Read the Audit Trail or your edge logs for it.

What an organisation sees of other organisations' traffic

The Platform API panel counts requests from every organisation on the deployment, and the Owner of any organisation can open it. An Owner therefore sees the deployment's total request volume and error shares, never another organisation's requests, callers or paths. The panel's detail view covers only your own organisation's requests, including its totals and charts, so the detail figures can be lower than the panel's.

A status records a condition, not a fix

A degraded or outage entry means a monitored signal crossed its configured condition. Read the affected panel for the cause and impact. The page records that the condition existed and says nothing about whether anyone resolved it. A chain that stops making progress while its process keeps serving requests is not a wedged process, so nothing restarts it. The stalled chain shows on this page and in readiness, and an operator decides what to do.

Frequently asked questions

Who can see the Platform status page?

A platform admin or the organisation's Owner. A system role such as System manager does not open it.

Was this page helpful?