Monitor platform status
Read the Platform status page to check overall health, data freshness, transactions, API, and workflow execution before relying on the platform.
The Platform status page reports the live health of the platform's core services from the platform's own telemetry. Use it to answer one question before you rely on the platform for an operation: is each service healthy now, and has it stayed healthy across recent days?
Open it from Console > Organisation settings > Operations > Platform status, or go directly to /platform-settings/status.
The page reads telemetry only. It reports current and recent operational signals. It never changes token, wallet, compliance, workflow, or chain state. To consume the same signals from an integration or monitoring system, use the platform status endpoints.
Who can view it
Platform status requires the on-chain admin or system manager role for the active system. An account without one of those roles sees an authorization notice instead of the panels. Access fails closed, so partial or missing role data also hides the page.
This matches the read scope of the platform status API: the page and the endpoints answer to the same permission set.
What the page shows
The page is built from four parts, top to bottom:
- Overall verdict at the top, rolled up from every panel.
- Operational metrics stat cards for the last 24 hours.
- Four service panels: Data freshness, Transactions, Platform API, and Workflows.
- Daily history showing the worst severity observed per service per day.
Each panel and the header refresh on their own, so a slow service cannot block the rest of the page from loading.
Read the overall verdict
The header shows a single rolled-up verdict with the timestamp of the last update. The platform combines the four panel verdicts in severity order, so the header reflects the worst current signal.
| Verdict | Meaning |
|---|---|
| All systems operational | At least one panel has current healthy observations and no panel reports a worse signal. |
| Degraded service | A panel reports degraded observations. Investigate before relying on the affected surface. |
| Service disruption | A panel reports outage-level observations. Treat this as incident-response input. |
| No data yet | No panel has usable observations yet, which is common in a clean or newly deployed system. |
Service disruption wins over Degraded service, which wins over All systems operational. The header reports No data yet only when no panel has operational data.
No data is not the same as healthy
Treat No data yet as an honest neutral state, not as proof the platform is healthy. A clean or freshly deployed
system has not produced enough telemetry to classify yet. Use Degraded service and Service disruption for incident
handling, then open the affected panel to see which signal changed.
Read the operational metrics
Most stat cards summarize the trailing 24 hours and show the change against the previous 24-hour window when a comparison is available. Blocks indexed is a running total, not a 24-hour figure, and shows no period-over-period change.
| Stat card | What it reports |
|---|---|
| Operations completed | Settled workflow completions in the last 24 hours, with change. |
| Success rate | Share of workflows that completed successfully, with change. |
| Completion time | The time within which 95% of successful workflows finished. |
| Data delay | Worst current sync-lag across chains, measured in blocks. |
| Blocks indexed | Total blocks indexed across the tracked chains to date. |
A card shows No data yet when the platform has no value for that metric in the window.
Read the service panels
Each panel carries a verdict, a plain-language consequence, supporting stats, and a recent-trend sparkline. Read the consequence line first. It tells you what the verdict means for the work you are about to do.
| Panel | Answers | Healthy means | Supporting stats |
|---|---|---|---|
| Data freshness | Is on-chain data landing in the Console on time? | On-chain data lands on time. | Chains in sync, sync errors in the last 24 hours. |
| Transactions | Are transactions reaching chain? | Transactions submit and confirm normally. | Tracked chain count. |
| Platform API | Are API requests succeeding? | API requests succeed normally. | 24-hour request volume, 4xx rate, 5xx rate. |
| Workflows | Are workflows completing? | Workflows are completing normally. | Completed in the last 24 hours, currently stalled count. |
When a panel reports Degraded service or Service disruption, open the matching panel endpoint to inspect the underlying signal: data freshness, transactions, platform API, or workflows. For elevated authentication failures specifically, use API monitoring, because authentication failures are not counted as platform API degradation.
Read the daily history
The history section shows the worst severity observed each completed UTC day for each service, oldest first. Use it to tell a one-off blip apart from a pattern. A single degraded day next to healthy days reads differently than several degraded days in a row.
History covers a trailing window of up to 30 days. When the platform has not recorded enough days yet, the section reports that no history is available.
When a section is unavailable
A service panel, the stat cards, or the history section can fail to load on its own without taking down the rest of the page. The affected section shows an unavailable state in place, so the rest of the page stays readable.
The page has one retry control, in the header, and no per-section retry buttons. The header retry appears only when one or more of the four service panels fails to load. Using it rechecks the four panels and the daily history together.
A stat-card failure does not bring up the header retry, and the header retry does not recheck the stat cards. If the operational metrics or history are unavailable on their own, reload the page to recheck every section.
If every panel fails to load, the header reports that status is unavailable. Retry from the header to recheck the page's signals.
What to do next
- Run a system update or review advanced accounts from the same Operations area in Platform setup overview.
- Work through tasks that are ready to act on in the Actions work queue.
- Wire the same signals into an external monitor with the platform status endpoints.
Actions work queue
Review upcoming, pending, completed, and expired DALP actions from the operator queue.
Rotate claim signer key
Operational runbook for rotating the autonomous EOA that signs claims on a compliance provider's claim-issuer identity. Rotation happens via addKey / removeKey on the identity and does not require any trusted issuers registry mutation.