Debug information export

Overview

When you run DALP in your own environment, a support engineer often cannot reach the cluster to diagnose an incident. The debug information export closes that gap. An administrator generates one point-in-time bundle that captures the whole environment, then hands it to support for offline diagnosis. No shell, no cluster credentials, and no live screen-share are required.

The export matters most for banks and regulated operators running restricted or air-gapped deployments, where granting outside access to production is not an option. The bundle is assembled from signals DALP already stores, passes through a single fail-closed redaction step, and arrives as a structured set of files a support engineer can read on their own machine.

This page is the reference for the bundle: the endpoint that produces it, the manifest contract, the category set, and the ways an administrator can trigger it. To read live operational panels instead of a one-time export, see Platform status endpoints.

Access and scope

Generating a bundle requires an authenticated DALP account with platform-status access for the active organisation and system. It uses the same administrator-gated authorization as the rest of the platform-status surface, so an operator who can read the status view can produce a bundle, and no one below that level can.

The export is a read. It collects state and never changes token, wallet, compliance, workflow, or chain data. Each response is a live snapshot taken at the instant the administrator triggers it, so the API marks the response Cache-Control: no-store. Treat each bundle as point-in-time evidence for one incident, not as a document to cache or reuse later.

Generate a bundle

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

The endpoint is a GET and takes no required parameters. The response is a JSON object with two top-level keys:

• manifest: the stable index of the bundle, described in Manifest contract.
• categories: the collected payloads, keyed by category id.

To narrow the time-ranged categories to a single incident, pass a window with from and to bounds. Each bound accepts an ISO 8601 timestamp, Unix seconds or milliseconds, or is omitted to take the default. The platform applies a bounded default window and a hard maximum span, so a request without a window still returns a sensibly scoped bundle rather than an unbounded history.

curl -G "$DALP_API_URL/api/v2/platform-status/debug-bundle" \
  --header "X-Api-Key: ${DALP_API_TOKEN}" \
  --data-urlencode "window[from]=2026-06-30T08:00:00Z" \
  --data-urlencode "window[to]=2026-06-30T10:00:00Z"

The window scopes the time-ranged sources, such as recent API request and error rows and any observability links. Categories that report fixed configuration or current service state ignore the window.

Manifest contract

The manifest is the part of the bundle a support engineer reads first, and the part you can rely on across versions. It carries a fixed schemaVersion of 1 and the following fields:

The platform block lets support cross-reference a bundle against a known build before reading any category. The observability block reports available: true with logs, metrics, and traces deep links when the deployment runs a dashboard stack, and available: false with no links when it does not. Either way the export succeeds, so the absence of dashboard links never blocks producing a bundle.

Category set

The bundle collects the environment in discrete categories. Each manifest entry names the category, its source, the time it was captured, and a status. The category id set is closed, so a consumer can rely on the identifiers staying stable:

Category status values

Each category reports one of four statuses. The status is itself diagnostic, so read it before reading the payload:

A category that fails never aborts the export. The collector guards each category on its own and degrades a failure to unavailable, so one unreachable subsystem cannot stop the rest of the bundle from shipping. A bundle missing a category is still useful, and the gap points support at the subsystem to investigate.

Redaction

The bundle serves an internal support audience, but that is not a licence to ship secrets. The platform routes every category payload through one fail-closed redaction step before it leaves the environment. That step runs two passes:

• It drops secret-named fields. A field name can mark it as a credential: a password, API key, access token, private key, mnemonic, or seed phrase. The platform removes the whole field rather than masking it. Dropping the field, instead of leaving a placeholder, also hides that the field existed.
• It scrubs embedded secrets from free text. The platform scans diagnostic text, such as an error message, for high-confidence secret shapes: connection-string credentials, provider API tokens, and bearer JWTs. It replaces each match in place with [REDACTED] and leaves the surrounding text readable.

The platform also drops any value that is not plain JSON-shaped data, since an opaque blob might carry a secret. It keeps transaction hashes, on-chain addresses, and administrator email addresses on purpose: a support engineer needs that detail, and none of it is secret. For a dashboard deep link, it strips embedded credentials from the base URL first.

When the platform drops a field or scrubs a value from a category it otherwise collected cleanly, that category reports redacted in the manifest, so a support engineer can see which payloads the platform sanitised. A category that already reports partial, because the platform truncated it or a sub-probe failed, keeps partial even when redaction touched it: the truncation is the more informative state to surface. This single chokepoint lets an administrator generate a bundle and hand it to support without a separate sanitisation step.

Trigger from the CLI

The CLI produces the same bundle. The CLI can write it straight to disk as a directory tree, the form a support engineer analyses:

dalp platform-status debug-bundle --out ./incident-bundle

With --out, the CLI writes manifest.json plus one <category>.json file per collected category into the target directory. Without --out, it prints the full bundle as JSON to standard output for piping into other tooling. Attach the directory form to a support request.

Trigger from the Console

An administrator can also export a bundle from the Console. Open the user menu and choose Export debug information to download a single zip. The item sits next to the issue-reporting control and is administrator-gated, so an administrator who can report an issue can also pull environment state, while a non-administrator sees only the issue-reporting control. The zip contains the same manifest.json and per-category files as the CLI directory output.

Operational notes

• Each bundle is a point-in-time snapshot. Generate a fresh bundle for each incident rather than reusing an old one.
• Read each category status before its payload. unavailable and redacted are expected states, not export failures.
• Scope recent-errors and api-requests to the incident with a window so the bundle stays focused.
• The export reflects whatever the environment can reach at that instant. A degraded subsystem appears as unavailable or partial, which is the signal support needs.

Related guides

• Platform status endpoints for the live operational panels and detail lists.
• Monitor platform status to read the same operational signals in the Console.
• API monitoring for request logs and API traffic metrics.
• Blockchain monitoring for chain, RPC, and indexer operational checks.