Platform health
The operational command-center that answers "is the platform healthy right now, and if not, where is the problem?" across every background subsystem.
Platform health gives an operations administrator one place that answers, in seconds, whether the platform is running correctly — and, when it is not, which subsystem to go and drill into. It is a read-only surface built from a small set of signal groups, each a card with a status tone (healthy, degraded, or critical) that drills into the surface owning the full detail. It is not a metrics wall; business counts (identities, accounts, entitlements) belong to the executive dashboard, not here.
A credible version of this page is also a trust signal during an evaluation — an evaluator who opens it and sees real, structured operational telemetry reads a mature product.
The overview surface
A single endpoint composes the whole page from reads that already exist elsewhere — it is an aggregation, not a new data model. The response carries a computed_at timestamp and an overall_status derived from the individual groups, plus one block per signal group. The page shows an overall badge at the top, then the cards.
overall_status is derived: critical when the core database is unreachable or a safety breaker or rate-limit is tripped; degraded when a connector is in error, provisioning failures cross a small threshold, migrations have drifted, an agent has gone quiet, or a tracked background sweep is erroring; otherwise healthy. A single card can show amber while the overall badge stays healthy, if nothing crosses the critical threshold.
Signal groups
| Signal group | What it rolls up | Drills into |
|---|---|---|
| Core | Database reachability and latency; whether schema migrations are at head or have drifted | Inline migration-drift detail |
| Connectors | Count of connected systems by health status; 24-hour sync success and failure counts | Imports |
| Provisioning | Failed and blocked provisioning-job counts, grouped by failure reason | The Failed Jobs queue |
| Reconciliation | 24-hour reconciliation runs, drift found, actions applied | Reconciliation detail |
| Safety | Tripped circuit-breakers and rate-limits out of the total | Safety-limits configuration |
| Agents | Tier-3 agent liveness by status, plus how long since the quietest agent was last seen | Agent management |
| Secrets | Secret-backend reachability — how many registered vault backends are unreachable | Secret-backend registry |
| Trial | For proof-of-concept tenants only: days remaining (negative once expired) | — |
| Scheduler | Health of every background sweep (see below) | — |
| ServiceNow relay | Health of the IT service management (ITSM) ticket-relay sync | Manual tasks |
| Backup | Last successful tenant backup and its status | — |
The trial card is absent entirely for non-trial tenants — not greyed out, simply not rendered. Where a group has nothing configured (no agents registered, no vault backends), it degrades to a calm "nothing configured yet" state rather than a red tone.
💡 Tip
Platform health never fixes anything — every "action" on the page is a navigation to the surface that owns the real fix. An administrator drills in, fixes at the owning surface, then returns to confirm the card has cleared to green against live data.
The scheduler sweep-run health tracker
Behind the scenes, roughly twenty background sweeps run on their own cadences — reconciliation, risk scoring, usage-data ingest, tier backups, ticket relay, and more. Historically each sweep only kept an in-memory marker of when it last ran, so there was no durable, visible answer to "is one of them stuck?"
Every sweep now records each pass into a persisted sweep-run tracker, keyed by tenant and sweep kind. One row per sweep kind per tenant is updated on every pass with:
last_run_at— when the sweep last completed a pass for this tenant.last_status—ok,error, orskipped.last_error— the error text of the most recent failing pass.consecutive_failures— a running count.
The recording is deliberately defensive and isolated: it uses its own short-lived session and swallows every one of its own exceptions internally. Health tracking must never break, slow, or roll back a production-critical sweep — observability is purely additive to the sweep's real work.
How the tracker reads out
The scheduler signal group summarizes the tracker into a small rollup plus a short list of the worst offenders (erroring first, then most overdue). The semantics are precise, and deliberately conservative about what counts as unhealthy:
- OK — the sweep's most recent pass succeeded.
- Erroring —
consecutive_failureshas crossed the failure threshold. This is what drives the card's tone; a single failure does not. - Overdue —
last_run_atis older than the sweep's expected interval times a grace factor, and it is not already counted as erroring. The expected interval mirrors each sweep's real cadence, so "overdue" means genuinely late, not merely idle. - Never run — there is no row yet for this sweep kind. This is not unhealthy: a fresh tenant with no eligible data (for example, no batches yet for a batch-archive sweep) simply has nothing to sweep. It does not affect the card's tone.
consecutive_failuresresets to zero on a successful pass, increments on an error, and is left untouched on a skip — a skip is not a failure, but it is also not evidence of health.
ServiceNow relay and backup health
The ServiceNow relay and backup groups read from the same sweep-run tracker — they are simply the ticket-relay and tier-backup sweep kinds surfaced as their own small cards, not a separate mechanism. Each shows whether it is tracked at all (a sweep that never ran for this tenant is not an error — for example, a tenant that has never had a ticket-backed task, or a plan not eligible for scheduled backups), its last status, last run time, last error, and consecutive-failure count. A tenant not on a backup-eligible plan simply shows the backup group as untracked.
Never a fake-green checkmark
The backup group carries one strict rule about its headline timestamp. last_successful_backup_at is set only when the most recent attempt succeeded — never a stale timestamp from an earlier success held over after a later failure. If the latest attempt failed, the surface shows an honest empty state ("no successful backup recorded") rather than a reassuring but false green tick from a backup that succeeded days ago. Presenting a last-known-success independent of the most recent outcome is exactly the fake-green-checkmark the design forbids.
Who can see it
Platform health is platform-operations oversight, not a business or scoped-ownership surface. An operations administrator gets the full surface with drill-in links; an auditor gets the same view read-only (there are no actions to gate anyway). Business roles and end users have no access and see no navigation entry for it. It is global by design — a tenant-wide aggregate, never scoped to one owner or one system.