SettleMint
ConceptsOperating

Platform Health

Platform Health lets a platform admin see in one glance whether the platform is healthy right now, instead of checking a dozen dashboards.

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. API errors reads operational, Chain RPC and indexer reads operational, Workflow completion 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. API errors reads operational, Chain RPC and indexer reads operational, Workflow completion 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. One degraded panel is enough to degrade the whole page: a rollup of independent panels always takes the worst verdict among them, never an average.

Every panel resolves to one of four verdicts: outage, degraded, operational, or no_data for no signal to judge, not just thin traffic.

The Platform Status page is restricted to platform administrators and system managers, because whether the platform itself is healthy is not a question any single organization's own traffic can answer.

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.

Why one verdict, not a dozen dashboards

An admin who wants to know whether the platform is fine right now should not have to reconcile a dozen separate charts to answer a yes-or-no question. The Console's Platform Status page exists to answer that question directly, in one of four states. A genuine incident reads as outage or degraded, and routine background work still reads as operational, so the page never raises a false alarm over ordinary maintenance.

The verdict is also not per-tenant. It aggregates request and infrastructure telemetry across every organization on the platform: whether the platform itself is healthy is a platform-operator question, and no single organization's own data can settle it alone.

Reading the Platform Status page

The Platform Status page groups what it reports into independently loading panels, an API panel, chain and indexer panels, a workflow-completion panel, and a data-freshness panel. A panel still waiting on its own data shows its own spinner while the rest of the page stays ready to read. A history section below shows how the same rollup looked over recent time, hour by hour, so a transient dip that already recovered stays visible as a blip instead of disappearing the moment it clears. 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 the day it belongs to, so a short outage colours only the hours it lasted. The history covers full UTC days only; the day still in progress is not part of it yet, because not every telemetry source publishes a partial day at the same pace.

Verdicts follow a fixed vocabulary of outage, degraded, operational, or no_data for a panel with no traffic and no signal at all to judge. A chain that is reindexing after a restart or backfill still reports operational, because rebuilding state is the indexer working as designed, and treating routine backfill as a red banner would make the page useless on every restart.

Two different rollups, and a separate probe split underneath

Panel rollups follow two different rules depending on what they aggregate. Independent panels roll up to the worst verdict among them, because one degraded panel is a real problem no matter how healthy the other three are. Redundant providers, like the chain-RPC (Remote Procedure Call) upstream pool behind a single chain, roll up to the best verdict instead. A chain stays operational while any one of its upstreams answers, and the pool only degrades once every upstream in it does.

Underneath the Console page, /readyz is a real dependency check. A merged readiness service combines the indexer's own readiness evaluation with whether the Workflow Engine is mid-shutdown, and the route reports healthy only when Postgres, the indexer, and the Workflow Engine all agree. Liveness answers a narrower question, on a port of its own. A thread that runs 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 process whose loop has seized recovers without anyone watching, while a slow dependency costs the process its place in the load balancer and nothing more. That dedicated port is the Platform API pod's. The workflow runner and indexer pods run their own images and answer liveness on the health port their main loop serves. A seized loop there stops answering the probe, 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. The contrast is the point. 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. The contrast is the point. A failing dependency stops traffic reaching the process; only the process's own loop seizing gets it restarted.

Readiness fans out to three real dependency checks and fails closed if any disagree, which stops traffic reaching the process. Liveness ignores dependencies entirely and watches only whether the process's own loop is still turning, which is the one condition worth a restart.

The readyz and healthz contract

Two checks decide whether a pod stays in service. /healthz on the API port returns { status: "ok" } and cannot fail; a deployment uses it to confirm the process has finished starting. Liveness is answered on a port of its own. /readyz fans out concurrently to a dedicated Postgres probe, budgeted at eight seconds, and a host probe that reads the merged readiness service, budgeted at one second. It reports ready only if the database is reachable and both the indexer and the Workflow Engine report healthy; any one failing returns 503 with the specific reason. Platform API not ready walks through diagnosing which dependency tripped it.

The API-error panel decides from integer request counts rather than floating-point rates, and the day's own request volume sets which ladder it is judged on.

Requests that dayConditionVerdict
0no requests at allno_data
Fewer than 50050 or more 5xx responsesoutage
Fewer than 500fewer than 50 5xx responsesoperational
500 or more5xx responses are 5% or more of the totaloutage
500 or more5xx responses are 1% or more, or 4xx responses are 50% or moredegraded
500 or moreotherwiseoperational

In the history, this ladder 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 that the volume split keeps operational therefore shows no red hour, and an outage day shows red only in the hours whose own error share crosses the line.

A day with no requests at all returns no_data, the verdict reserved for zero traffic rather than thin traffic. Unauthorized and forbidden responses are excluded from the 4xx count before it reaches the verdict, because an authentication failure says something about the one caller who sent it, and nothing about the platform underneath.

What the cross-tenant view is allowed to see

The API panel aggregates request telemetry across organizations for the same reason the whole page does: a platform-wide question needs platform-wide data. That widened scope is bounded by the same role gate that decides who can open the page at all, so the aggregate exists and nobody outside a platform administrator or a system manager ever sees it. No organization's operators reach another organization's traffic through this route.

What a status means, and what it does not

Because a routine reindex is mapped to operational rather than degraded, a degraded or outage entry indicates that a monitored signal crossed its configured condition. Read the affected panel to determine the cause and impact. The same discipline decides what the page is evidence of: it records that a condition existed, and stays silent on whether anyone fixed it. A chain that stops making progress while its process keeps serving requests is not a wedged process, so nothing restarts it; it shows up on this page and in readiness, and an operator decides what to do. An entry showing a chain in trouble is evidence that the trouble happened, not that anyone has resolved it yet.

Frequently asked questions

Does one slow-loading panel hold up the rest of the Platform Status page?

No. Each panel loads independently. A panel still waiting on its own data shows its own spinner while the rest of the page stays ready to read, so one slow source never blocks the others.

Why doesn't the history section include today?

The history covers full UTC days only. The day still in progress is left out because not every telemetry source publishes a partial day at the same pace, and including it early would show a rollup built on incomplete data.

Who can see the Platform Status page?

Platform administrators and system managers. Either role alone is enough; holding both is not required.

Do failed logins count against the API panel's verdict?

No. Unauthorized and forbidden responses are excluded from the 4xx count before it reaches the verdict. An authentication failure says something about the one caller who sent it, and nothing about the platform underneath.

Webhook Delivery

Webhook Delivery retries a signed notification for three days and records whether a counterparty was told, so an integrator skips its own retry logic.

Overview

Plan a topology and posture, prepare prerequisites, install the charts, integrate SSO and observability, and run the instance with upgrades and runbooks.

On this page

Why one verdict, not a dozen dashboardsReading the Platform Status pageTwo different rollups, and a separate probe split underneathThe readyz and healthz contractWhat the cross-tenant view is allowed to seeWhat a status means, and what it does notFrequently asked questionsRelated concepts