# Monitor platform status Source: https://docs.settlemint.com/docs/operators/runbooks/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](/docs/api-reference/observability/platform-status). ## Who can view it [#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 [#what-the-page-shows] The page is built from four parts, top to bottom: 1. **Overall verdict** at the top, rolled up from every panel. 2. **Operational metrics** stat cards for the last 24 hours. 3. **Four service panels**: Data freshness, Transactions, Platform API, and Workflows. 4. **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 [#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. 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 [#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 [#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](/docs/api-reference/observability/platform-status), [transactions](/docs/api-reference/observability/platform-status), [platform API](/docs/api-reference/observability/platform-status), or [workflows](/docs/api-reference/observability/platform-status). For elevated authentication failures specifically, use [API monitoring](/docs/api-reference/observability/api-monitoring), because authentication failures are not counted as platform API degradation. ## Read the daily history [#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 [#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 [#what-to-do-next] * Run a system update or review advanced accounts from the same Operations area in [Platform setup overview](/docs/operators/platform-setup/platform-overview). * Work through tasks that are ready to act on in the [Actions work queue](/docs/operators/runbooks/actions-work-queue). * Wire the same signals into an external monitor with the [platform status endpoints](/docs/api-reference/observability/platform-status).