# Platform status endpoints

Source: https://docs.settlemint.com/docs/api-reference/observability/platform-status
Read DALP platform-status panels, stat cards, and history from the current API.



## Overview [#overview]

The platform-status endpoints expose the same operational panels that back the DALP status view. Use them when an operations console, support runbook, or monitoring integration needs a compact view of platform health across data freshness, transaction infrastructure, API activity, and workflow execution. To read the same signals in the Console instead, see [Monitor platform status](/docs/operators/runbooks/monitor-platform-status).

The API surface is read-only. It reports current and recent operational signals. It does not change token, wallet, compliance, workflow, or chain state.

## Access and scope [#access-and-scope]

Platform-status calls require an authenticated DALP account with access to the platform status view for the active organisation and system. Responses are assembled from DALP operational telemetry and can return `no_data` when a fresh deployment or clean environment has not produced enough rollup data yet.

Treat `no_data` as an honest neutral state, not as proof that the platform is healthy. Use `degraded` and `outage` for incident handling, then move to the panel-specific endpoint to see which signal changed.

## Endpoint summary [#endpoint-summary]

Read the panel and stat-card endpoints for current state, and the history endpoint for the trailing strip.

| Purpose              | Method and path                              | Query parameters     | Use it for                                                                                                             |
| -------------------- | -------------------------------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Data freshness panel | `GET /api/v2/platform-status/data-freshness` | None                 | Check indexed-chain freshness, total tracked chains, and 24-hour sync-error count.                                     |
| Transactions panel   | `GET /api/v2/platform-status/transactions`   | None                 | Read transaction infrastructure status and tracked chain count.                                                        |
| Platform API panel   | `GET /api/v2/platform-status/platform-api`   | None                 | Review 24-hour API request volume, 4xx rate, and 5xx rate.                                                             |
| Workflows panel      | `GET /api/v2/platform-status/workflows`      | None                 | Check completed and stalled workflow counts when workflow telemetry is available.                                      |
| Stat cards           | `GET /api/v2/platform-status/stat-cards`     | None                 | Read compact operational cards for completed workflows, success rate, completion time, data delay, and indexed blocks. |
| History              | `GET /api/v2/platform-status/history`        | `days`, from 1 to 30 | Read per-service per-day worst severity for the trailing window.                                                       |

A legacy aggregate endpoint, `GET /api/v2/platform-status/snapshot`, is being retired. See [Legacy snapshot aggregate](#legacy-snapshot-aggregate) before you build on it.

## Verdict values [#verdict-values]

Platform-status responses use four verdict values:

| Verdict       | Meaning                                                                                                                   |
| ------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `operational` | At least one panel has current healthy observations and no higher-severity panel dominates the rollup.                    |
| `degraded`    | A panel has degraded observations that should be investigated before relying on the affected surface.                     |
| `outage`      | A panel reports outage-level observations. Treat this as incident-response input.                                         |
| `no_data`     | DALP has no usable observations for that panel or rollup yet. This often appears in clean or newly deployed environments. |

The platform rolls verdicts up in severity order: `outage` wins over `degraded`, `degraded` wins over `operational`, and `no_data` applies only when no panel has operational data. Combine the four panel verdicts the same way when you want a single header signal for a dashboard.

### Platform API verdict thresholds [#platform-api-verdict-thresholds]

The Platform API panel uses the trailing 24-hour request counts for its verdict. DALP treats zero requests as `no_data` because there is no activity to classify.

| Observation window                  | Verdict rule                                                                                         |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Fewer than 500 requests in 24 hours | `operational`, unless there are 50 or more 5xx responses. 50 or more 5xx responses returns `outage`. |
| 500 or more requests in 24 hours    | 5xx responses at 5% or higher return `outage`.                                                       |
| 500 or more requests in 24 hours    | 5xx responses at 1% or higher return `degraded` when the 5% outage line is not reached.              |
| 500 or more requests in 24 hours    | Non-authentication 4xx responses at 50% or higher return `degraded`.                                 |

Authentication failures are not counted as platform 4xx degradation. Treat them as client or credential signals and use [API monitoring](/docs/api-reference/observability/api-monitoring) to inspect the request path before escalating the platform-status verdict.

### Workflow verdict thresholds [#workflow-verdict-thresholds]

The Workflows panel compares currently stalled workflows against the completed-workflow count from the trailing 24-hour window. When DALP cannot determine the completed count, the panel returns `no_data`. This matters because zero stalled workflows and an unknown completed count are different states: the first is clean, the second is inconclusive.

| Workflow observation           | Verdict rule                                    |
| ------------------------------ | ----------------------------------------------- |
| Completed count is unavailable | `no_data`, even when the stalled count is zero. |
| Stalled rate below 2%          | `operational`.                                  |
| Stalled rate at 2% or higher   | `degraded`.                                     |
| Stalled rate at 5% or higher   | `outage`.                                       |

Use the Workflows panel to decide whether to inspect workflow recovery. See [Workflow engine recovery](/docs/developers/operations/workflow-engine-recovery) when stalled or missing workflow signals need operator follow-up.

## Read a focused panel [#read-a-focused-panel]

Each panel endpoint covers one operating area. A dashboard or runbook calls the data-freshness, transactions, platform-api, or workflows endpoint directly and reads only the signals it needs.

```bash
curl "$DALP_API_URL/api/v2/platform-status/data-freshness"   --header "X-Api-Key: ${DALP_API_TOKEN}"

curl "$DALP_API_URL/api/v2/platform-status/platform-api"   --header "X-Api-Key: ${DALP_API_TOKEN}"
```

Each panel response includes `generatedAt`, a `verdict`, a `sparkline`, and a panel-specific `stats` object. Sparkline points use hour-aligned `bucketHour` timestamps and a numeric `value`; `value` can be `null` when the bucket has no observations.

The data-freshness panel reports `chainsInSync`, `totalChains`, and `syncErrors24h`. The platform API panel reports `totalRequests24h`, `error4xxRate`, and `error5xxRate`. Rates are returned as fractions from `0` to `1`; multiply by 100 only in the display layer.

Workflow fields such as `completed24h` and `stalled` can be `null` until workflow telemetry is available. Do not coerce those values to zero in monitoring code, because zero and unknown mean different things.

## Read the stat cards [#read-the-stat-cards]

Use the stat-cards endpoint when a dashboard needs the compact operational numbers alongside the current-versus-previous comparison window.

```bash
curl "$DALP_API_URL/api/v2/platform-status/stat-cards"   --header "X-Api-Key: ${DALP_API_TOKEN}"
```

The response reports trailing-24-hour values and the matching previous-24-hour values for completed operations, success rate, and P95 completion time, plus the worst data-delay in blocks, the timestamp that delay was measured at, and the total indexed block height. Each value can be `null` when DALP could not produce that metric for the window, so keep the unknown state distinct from zero in display and alerting code.

## Read trailing history [#read-trailing-history]

Use history when you need a compact strip of recent severity by service.

```bash
curl -G "$DALP_API_URL/api/v2/platform-status/history"   --header "X-Api-Key: ${DALP_API_TOKEN}"   --data-urlencode "days=14"
```

`days` defaults to 30 and is capped at 30. Each row identifies the status kind, provides a human-readable service label, and returns oldest-first day cells with a UTC date and the worst severity for that service on that date.

## Legacy snapshot aggregate [#legacy-snapshot-aggregate]

`GET /api/v2/platform-status/snapshot` returns the header verdict, all four panel verdicts, and stat-card values in one response. This aggregate is a legacy convenience endpoint and is being retired. Its responses carry standard HTTP `Deprecation` and `Sunset` headers, along with `Link` headers pointing to the successor endpoints.

Build new integrations on the panel and stat-card endpoints instead. They return the same signals, let each dashboard or runbook read only what it needs, and are not scheduled for removal:

* `GET /api/v2/platform-status/data-freshness`
* `GET /api/v2/platform-status/transactions`
* `GET /api/v2/platform-status/platform-api`
* `GET /api/v2/platform-status/workflows`
* `GET /api/v2/platform-status/stat-cards`

If you call snapshot today, read the `Sunset` header for the retirement date and migrate before it. To reproduce the rolled-up header verdict, combine the four panel verdicts in severity order: `outage` wins, then `degraded`, then `operational`, then `no_data`.

## Operational notes [#operational-notes]

* These endpoints are status and observability reads, not availability guarantees.
* `no_data` should be displayed separately from `operational`.
* Nullable stat-card values mean DALP could not produce that metric for the current window.
* Use [API monitoring](/docs/api-reference/observability/api-monitoring) when you need request logs, endpoint metrics, and API traffic timelines.
* Use [blockchain monitoring](/docs/developers/operations/blockchain-monitoring) when you need chain, RPC, indexer, or transaction operational checks.

## Related guides [#related-guides]

* [API reference](/docs/api-reference/reference/openapi) for the generated OpenAPI contract.
* [API monitoring](/docs/api-reference/observability/api-monitoring) for request logs and API traffic metrics.
* [Workflow engine recovery](/docs/developers/operations/workflow-engine-recovery) for operator recovery steps after checking workflow state.
* [Blockchain monitoring](/docs/developers/operations/blockchain-monitoring) for chain and transaction monitoring workflows.