# 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`. For SettleMint-hosted environments, the public [SettleMint status page](https://status.settlemint.com/) reports platform-wide availability and incident history outside the Console. Use the Console page for tenant-scoped telemetry; use the status page when you need SettleMint's published service 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] To view Platform status, your account needs the on-chain **admin** or **system manager** role for the active system. Without one of those roles, you see 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, so the same role that unlocks the page also covers the endpoints. ## What the page shows [#what-the-page-shows] The page is built from four parts. At the top, an overall verdict rolls up the signal from every panel below it. Below that, operational metrics stat cards cover the last 24 hours. The four service panels follow: Data freshness, Transactions, Platform API, and Workflows. At the bottom, a daily history shows the worst severity 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 carries no period-over-period comparison. | 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 high authentication failure rates specifically, use [API monitoring](/docs/api-reference/observability/api-monitoring), because the platform does not count authentication failures 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 yet recorded enough days, you see a notice 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 area shows an unavailable state in place, so you can still read the rest of the page. The page has one retry control in the header and no per-section retry buttons. That control appears only when one or more service panels fail to load; using it rechecks those four panels and the daily history together. A stat-card failure does not trigger it, and the control does not cover the stat cards. If operational metrics or history are unavailable on their own, reload the full page to recheck every section. If every panel fails to load, the header reports that status is unavailable. Use the header retry 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 pending operator tasks in the [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). * Check [SettleMint status](https://status.settlemint.com/) for published availability on hosted environments, or review [SettleMint Trust Center](https://trust.settlemint.com/) security and compliance documentation for procurement or audit evidence.