System Health
What this screen is for
System Health is the internal half of the question the Integration Topology asks of the outside: are the platform's own services up, are they serving normally, and what are they consuming? It shows one document: the last evaluation the platform's alert evaluator made of every service, with the host node underneath, the alert conditions that are firing, whether notification delivery is ready, and whether the deployment would survive the loss of its host. Nothing on this screen changes the platform; its two links open the settings that do.
The document is not probed when you open the screen. The evaluator performs one fan-out per interval, stores the result, and this screen and the alerting read that same stored evaluation, so the panel and the alerts cannot disagree. The reading you see may therefore be up to one interval old, and the screen says exactly how old.
What must exist first
This is a platform screen, reached in the platform context. Its sidebar entry is shown to every platform role; each read on it then needs its own permission and degrades alone:
- The permission to read platform observability, for the tiles, the service table, the Recovery readiness card and the Database card. The built-in platform administrator, operator, auditor and viewer roles all hold it. Without it the screen says platform health is temporarily unavailable, the readiness card says the readiness could not be determined, and the Database card is not shown.
- The permission to read platform alerts, for the Alerts strip. Without it the strip says the alert configuration could not be loaded, never that nothing is firing.
- The permission to read platform notification settings, for Notification delivery. Without it the read is not made and the row says delivery readiness could not be determined.
Until the first evaluation completes, the screen says no evaluation has completed yet and shows no counts, rather than a green zero.
Decisions you make here
Reading when it was measured
Measured prints the instant of the evaluation, to the second, as the server reported it; the console never converts it to an age. When the server judges the evaluation older than it can vouch for, a dashed marker says Last known reading — the evaluator has not reported since: the rows and their time stay on screen, marked, never emptied.
The interval is 60 seconds unless the alert evaluation interval was changed under Platform Settings, which applies without a restart; the staleness bound is twice the sum of the interval, the fan-out's own deadline and the reads each evaluation makes before it starts, 182 seconds at the defaults. The screen re-reads the document when it is a minute old and the window regains focus.
Reading availability
The four tiles partition the probed services into Services available, Unavailable and Unmeasured, which always sum to the total, plus Degraded, which is drawn from the available ones. Availability comes from each service's liveness probe:
- AVAILABLE: the probe answered and the service reports itself live.
- UNAVAILABLE: the probe answered and the service reports itself not live. Evidence about the service.
- UNMEASURED: no answer was obtained, because the probe timed out after two seconds, the whole fan-out reached its ten-second deadline, or the container could not be reached. Evidence about the prober, not about the service; it is not an outage and is never coloured as one. When the fan-out expires, every service reads unmeasured at once.
Every platform service is probed by default, and the deployment may override the list.
Reading serving
Serving is the readiness signal, reported only for a service whose availability was measured: READY when every readiness component is up; not ready: name, naming the component responsible, or unknown when none isolates; unknown when the readiness gauge could not be read. Degraded counts the services that are available but not ready, and the summary on the Platform Overview names them. An unavailable service shows no serving chip, because nothing was probed. The detail text, when present, says only that resource metrics were unavailable; it never names a cause.
Reading resources
Per service: CPU trend, a sparkline built from the samples observed while this page is open, up to thirty, so it starts as a single point and fills in; Heap used / max; Disk free; and Uptime. Host node carries the host's CPU, memory and disk from the collector's host-metrics listener, and reads unavailable until that listener is deployed. Any figure the probe could not read prints unavailable rather than zero, and a meter is unavailable as a whole when either side of it is.
Reading the alerts strip
Alerts lists the alert conditions that are firing, then those that are pending, each with its severity, the value the evaluation observed and when it was measured, a note when that measurement is from an earlier evaluation than the one now served, and how many notifications the cooldown suppressed.
A PENDING condition holds but has not yet held for its dwell, so nobody has been notified; its row reads Holding since the start of that dwell and when it notifies after. It becomes FIRING once the dwell completes, and only then is a notification sent.
An alert message opens this screen on its own condition. A firing or pending row is highlighted in place; a quiet or resolved one appears as a Linked condition card with its current state and last measured value.
Evaluated is the time of the same evaluation the tiles come from. No condition is firing. means none is firing or pending, and is a measured statement; a failed read says so instead. Below the firing rows, the number of key materials approaching expiry is informational and never a firing row; when the horizon was not measured this evaluation the strip says so rather than showing zero. Configure alerts opens Platform Settings, where conditions, thresholds and destinations are managed.
Reading recovery readiness
The Recovery readiness card answers one question: would this deployment survive the loss of its host? The server decides the answer from the backup runs the environment host reports, and the card shows the server's verdict and reasons as given, never one of its own. The backup alerts read the same answer, so the card and the alerts cannot disagree.
- Unknown: the host has never reported a backup run. Nothing was measured, so this is not the same as not ready.
- Not ready: the latest run found no usable escrow recipient, or no backup has ever succeeded.
- At risk: the latest run failed, the last successful backup is older than the deployment allows (7 days by default), or no copy off the host is declared for it.
- Ready: none of these holds.
Every reason that holds is listed under the verdict. A reason this console does not recognise is shown with its code rather than hidden. While the read is in flight the card says so, and a refused or failed read says the readiness could not be determined; the card is never blank.
Each fact carries where it came from. Measured by the host marks what a backup run reported, with the time it was received: the escrow key's state and fingerprint, the host signing key's fingerprint, the last successful backup with its time and number of sealed files, and the last run with its time and outcome. Declared by the operator marks the copy off the host, which the platform cannot see: the operator declares it on the host after copying the backup, and the platform accepts it only for the archive of a backup it recorded.
DR rehearsal: not recorded by the platform is always shown. Whether a restore onto another host actually works is proven off the host, by the Disaster-Recovery Certification page of the operations documentation; the steps behind every row are in its Backup and Restore page.
Reading the database
The Database card describes the deployment's PostgreSQL server. It changes nothing, and nothing on the platform gates, alerts or decides readiness on it. Each value carries where it came from:
- Measured: the server version, read by the platform from its own database connection.
- Declared: the database mode, Bundled when the platform runs PostgreSQL itself or External when it runs on the customer's server, and the backup mode, Platform for the platform's own backups or Provider for the database provider's snapshots, which the platform does not observe.
- Reported by the host: the last database preflight, which the environment host runs before every deployment.
The preflight line shows its verdict, the first check that failed, the server's major version and its TLS floor, and when it ran. The TLS floor is the server's minimum protocol as the host read it, not a measurement of this connection; the platform requires TLS 1.3, and a host that may not read the setting reports none.
The server decides how old the preflight is, and the card shows that decision as given:
- Current: it ran within the last 7 days. A current preflight can still be a refusal.
- Stale: it ran longer ago. Its verdict is a last-known one, never a pass.
- Absent: the host has never reported one. Nothing was checked, so it is never a pass either.
A refused preflight names the check to fix. Its causes and remedies are in the External PostgreSQL page of the deployment documentation.
Reading notification delivery
Notification delivery states, per channel, whether delivery is working or what blocks it, with Configure delivery providers beside a blocked channel. It is present in every state: a ready channel is a statement, not an absence, and a read that failed says delivery readiness could not be determined.
How it relates to other screens
The Platform Overview carries the compact summary of this same document, with View System Health leading here:
Whether the systems the platform connects to outward are healthy is the Integration Topology's question: