Platform status reports the health of the platform's service areas and outbound deliveries, with the figures and the history behind each verdict. Use it to identify the service that needs investigation. The page only reads. The actions that recover a stuck transaction are on the Transactions detail view.
Check this page first when something elsewhere in the Console looks wrong, to see whether a platform area is degraded. A green page does not rule out a fault in one operation. For a SettleMint-hosted environment, the public SettleMint status page reports platform-wide availability and incident history outside the Console. Use this page for this deployment's telemetry. Use the status page when you need SettleMint's published service status. The SettleMint Trust Centre publishes SettleMint's security and compliance documentation.
The “Platform status” page with the “All systems operational” badge.
Each service area has a card: “Data freshness”, “Transactions”, “Platform API”, “Workflows”, “Webhooks” and “Email”. Each card shows a status bar, figures for the last 24 hours and a “Details” link to a detail view.
Steps
Read the overall status
The header shows the overall status pill, the Version of the running platform, and, when your deployment sets a Grafana address, a “Dashboards” link that opens it in a new tab. How the overall status is chosen explains the pill. While the status loads it reads “Computing overall status…”. If the read fails, it reads “Status unavailable” with “All status panels failed to load.” and a “Try again” button. A line under the pill reads “No data from” and the areas that have nothing to report.
Resolve held bundles
When the custody provider holds bundles, a notice above the panels reads “1 bundle waits at the custody provider”, and the number changes with the count. With none held, the notice does not show. An approval rule at the custody provider holds these bundles, so every user operation in them waits.
The notice lists the “Provider”, the “Reference”, the “Chain” and “Held for” of each bundle. “Provider” names the provider the custody configuration was added as, such as “IBM Digital Asset Haven”. Select Copy the provider reference to copy the reference, open the request at the custody provider by that reference, and approve or reject it there.
The notice shows the oldest bundles and reads “This list shows the 20 oldest of 25 held bundles.” when more are held. If the list cannot be read it says “The held bundles did not load. A bundle the custody provider holds may be missing from this page.”
Open the panel that is not operational
Each area is a panel with a verdict badge, a 24-hour trend and its figures. A panel says what its trouble costs only while it is degraded or in an outage. Select a panel's Details link to open its detail view, then read its status and recent signals to decide what to check next. To recover a stuck transaction, open “Transactions” and follow Platform status transactions. Panels and figures lists what each panel counts.
Read the history
Below the panels, the 30-day history grid reads “Status by UTC hour for the last completed days. Short incidents color only the hours affected.” Hover a cell to see its date, UTC hour range and verdict. Use the grid to tell a brief incident from one that ran all day, and whether the latest signal is a one-off blip or part of a growing trend. While the history loads, and when no hour has data, the grid keeps the same size and the legend still lists every verdict. Hours with no data read “No data”.
How the overall status is chosen
The Platform Health summary uses the worst verdict across the four core areas. Webhooks, when you can manage webhooks, and Email, FIX sessions, Batch jobs and Scheduled jobs join it only while they are degraded or in an outage. One degraded area makes the summary amber, even if the others are healthy.
The header pill and the panel badges use different words for the same four verdicts:
The header shows the highest rank among the areas that answered. An area that reads “No data” contributes no verdict, but it is never read as healthy: “All systems operational” appears only when every area answered with a measured verdict. When the measured areas are all operational and at least one area has nothing to report, the header reads Partially reporting in grey instead, and a line under it names the areas with no data. A degraded or outage verdict elsewhere still shows its own colour and label, with the same line naming the silent areas beneath it.
Panels and figures
Every figure covers the “Last 24 hours” and appears once, in the panel of its service. “Delay now” is the current reading, not an aggregate. “Indexer head” is a running total across every connected chain. A panel with nothing to measure shows a dash for each figure. Data freshness, Transactions, Platform API and Workflows load from one read. If that read fails, all four show an error and a Try again button. That state means the page could not reach the platform, not that the platform has no data. The other panels load on their own. While a panel loads, it shows its outline: the same bars, legend and figure rows, so nothing moves when the figures arrive.
The Webhooks panel reads its bars, its “Delivered” and “Success” figures, and its “Failing endpoints” figure separately. When one read fails, the panel keeps what the others returned and marks only the figures that read feeds with a dash and “Unable to load this section”. When the bars read fails, the panel shows an error and a Try again button where the bars would be.
The Workflows figures describe volume and throughput, and they can look strong while the panel reports degraded. A degraded Workflows verdict means work completes slowly. An outage means it does not complete.
The Webhooks detail page also counts the events queued or waiting to retry across every endpoint, up to 10,000 (a count at the ceiling reads “10,000+”), shows how long ago the oldest of them was queued, and ranks the last 24 hours' failures by class.
Outbound panels
The Email, FIX sessions, Batch jobs, and Scheduled jobs panels count every attempt the platform makes to reach something outside it: an email handed to the mail server, a FIX logon or message sent to a counterparty, a document generated in the background, or a run of a scheduled job.
They use the same rule as the transaction failure verdict: with 20 or more attempts in the last 24 hours, failures on one in twenty make the panel degraded and failures on half make it an outage. With fewer attempts, any failure makes it degraded and three make it an outage. The header counts these panels only when one is degraded or in an outage.
A platform administrator also sees attempts that belong to no organisation, such as scheduled jobs.
Each of these panels opens a detail view with an hourly chart of succeeded and failed attempts, a table of the sources behind the area (the email template, the FIX session, the job), and the most recent failures with their reason code. A reason is a short code such as the mail server's reply code or the FIX reject reason, never an address, a message text, or document content. Both tables export to CSV.
Troubleshooting
Platform status is not in the sidebar
The entry shows only to an organisation owner or a platform administrator. Ask one of them to open it, or to make you an organisation owner.
A signal looks stale
Each read on this page is cached for 30 seconds. The four core panels and the Transactions and Workflows detail lists refresh when a new health sample arrives. Reload the page to refresh the other areas. Completion time (p95) is recomputed about every 5 minutes, so it can trail the other Workflows figures by about 5 minutes.
A notice says bundles wait at the custody provider
An approval rule at the custody provider holds each listed bundle. Open the request at the custody provider by its reference and approve or reject it there. A held bundle is a fault in the provider's rules for the bundler wallets, not a step a user must take, so it never appears in a user's Actions. See Resolve held bundles.
Data freshness says indexer telemetry is not arriving
At least one chain registered for indexer health has no current sample. A sample older than three of its own collector ticks no longer counts as current, so the area stops showing the last verdict it saw and reads No data instead, even when the other chains are healthy. This is a fault in the health collector, not proof that the indexer is healthy or down: check whether indexed data elsewhere in the Console is current, and treat it as a monitoring outage until samples return.
Data freshness shows chains out of sync
The verdict comes from each network's latest indexer sample, and the tile's first line names the reason. Degraded means the indexer is 10 or more blocks behind the chain tip, is ahead of the tip it was checked against, or has indexed no new block for 5 minutes while blocks wait. Outage means it is more than 100 blocks behind, or has indexed no new block for 15 minutes while blocks wait. An indexer at the chain tip is in sync, however long the chain has gone without a new block. A chain that stops producing blocks shows under Transactions. While a chain is out of sync, anything reading indexed data (balances, transaction history, feed values) reflects an older state than what is on-chain. Open the data freshness detail view to see the current delay and how long it was unhealthy before assuming a specific balance or history view elsewhere in the Console is wrong.
Workflows shows a stalled count above zero
A stalled workflow is background work that started in the last 24 hours but has not progressed, distinct from one that failed outright. The count covers the same day as the completed count it is compared with, so a status row left running long ago cannot keep the area in outage. Open the workflows detail view to see which one is stuck. It still lists older runs that never finished. A growing stalled count or work that exceeds its expected processing time requires investigation.
The header reads “Status unavailable” instead of a verdict
This means none of the four areas answered the page's own query, a failed page load, not a platform verdict. A real degraded or outage state still shows its own colour and label instead. Try again reloads the status read, the held bundles and the history. If Try again keeps failing, check your own connection or session before assuming the platform is down.
An area reads “No data yet”
The area has no current telemetry: either it has not produced any yet, most often right after it first comes online, or its collector stopped. It never outranks a real degraded or outage state sitting elsewhere, and it never lets the header read “All systems operational”. The header names it under the verdict instead. If it does not clear after a normal refresh, treat it as a stale signal.
Frequently asked questions
If Data freshness shows a delay, does that mean a transaction of mine failed or is missing?
No. Data freshness reports how far the indexer that feeds the Console's reads (balances, transaction history, feed values) sits behind the chain tip. It says nothing about whether a submission reached the chain. A transaction that already confirmed on-chain can still look briefly missing here if the indexer has not caught up yet. Check Transactions instead for submission and confirmation health.
Why does the header briefly read "Computing overall status…" in grey?
The header reads “Computing overall status…” until the status read answers. A normal page load or reload passes through this state briefly, so it is not a sign that anything is wrong. If it does not clear, reload the page. If the read fails, the header reads “Status unavailable” and offers Try again.