Platform status endpoints
Read DALP platform-status panels, stat cards, snapshots, and history from the current API.
Overview
The platform-status endpoints expose the same operational status 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.
This is a read-only API surface. 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
| 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. |
| Snapshot | GET /api/v2/platform-status/snapshot | None | Fetch the header verdict, all four panel verdicts, and stat-card values in one response. |
| History | GET /api/v2/platform-status/history | days, from 1 to 30 | Read per-service per-day worst severity for the trailing window. |
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 snapshot header is rolled up in severity order: outage wins over degraded, degraded wins over operational, and no_data is returned only when no panel has operational data.
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 with the completed-workflow count from the trailing 24-hour window. If DALP cannot determine the completed-workflow count, the panel returns no_data instead of guessing.
| 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. Use Workflow engine recovery when stalled or missing workflow signals need operator follow-up.
Read the current snapshot
Use the snapshot endpoint when you need one call for a dashboard header or runbook gate.
curl "$DALP_API_URL/api/v2/platform-status/snapshot" --header "X-Api-Key: ${DALP_API_TOKEN}"The response includes:
generatedAt, the time DALP assembled the snapshot.headerVerdict, the rolled-up platform verdict.panels.dataFreshness,panels.transactions,panels.platformApi, andpanels.workflows.statCards, including workflow completion, success-rate, completion-time, data-delay, and indexed-block values.
Panel responses include a verdict and a sparkline. Sparkline points use hour-aligned bucketHour timestamps and a numeric value; value can be null when the bucket has no observations.
Read a focused panel
Use the focused endpoints when a dashboard or runbook already knows which operating area 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}"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 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.
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 actions after checking workflow state.
- Blockchain monitoring for chain and transaction monitoring workflows.
API monitoring endpoints
Query API traffic, latency, errors, request logs, and real-time API activity from the DALP monitoring API.
Reporting and audit access
Use DALP's indexed read APIs, dashboard exports, transaction references, webhook delivery records, and audit-access responsibilities for reporting and data retrieval.