Platform status endpoints
Read DALP platform-status panels, stat cards, and history from the current API.
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.
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
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
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 before you build on it.
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
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 to inspect the request path before escalating the platform-status verdict.
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 when stalled or missing workflow signals need operator follow-up.
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.
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
Use the stat-cards endpoint when a dashboard needs the compact operational numbers alongside the current-versus-previous comparison window.
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
Use history when you need a compact strip of recent severity by service.
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
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-freshnessGET /api/v2/platform-status/transactionsGET /api/v2/platform-status/platform-apiGET /api/v2/platform-status/workflowsGET /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
- These endpoints are status and observability reads, not availability guarantees.
no_datashould be displayed separately fromoperational.- Nullable stat-card values mean DALP could not produce that metric for the current window.
- Use API monitoring when you need request logs, endpoint metrics, and API traffic timelines.
- Use blockchain monitoring when you need chain, RPC, indexer, or transaction operational checks.
Related guides
- API reference for the generated OpenAPI contract.
- API monitoring for request logs and API traffic metrics.
- Workflow engine recovery for operator recovery steps after checking workflow state.
- Blockchain monitoring for chain and transaction monitoring workflows.
API monitoring
Query API traffic, latency, errors, request logs, and real-time API activity from the DALP monitoring API.
Transaction queue lifecycle and recovery
Reference for the DALP transaction queue API: list and filter queued requests, read lifecycle status, cancel pending transactions with replace-by-fee, and run operator recovery for stuck or dead-lettered work.