Observability

Warden collects telemetry on each node. The platform retains it for the period included in the deployment tier. Use {supervisor_url} for these Supervisor API requests.

Reading requires deployment:telemetry:read. Changing retention requires deployment:telemetry:manage.

Runtime and Response Shapes

Runtime paths accept iggy, connectors, and available connector:{id} instances. Latest deployment metrics use a nodes map keyed by node ID. Each node maps runtime names to arrays of samples. A host array can contain virtual-machine metrics. Historical requests return paginated samples.

Runtime fields appear directly in each sample. Iggy can report leadership, view, voters, quorum, replication gaps, and repair state. Managed backend metrics include projector lag, decoding counters, replay readiness, ownership, fencing, and backend synchronization. See Monitoring.

Metrics

Get Deployment Metrics (Latest)

curl {supervisor_url}/deployments/{deployment_id}/metrics \
-H "ld-api-key: YOUR_API_KEY"

Get Node Metrics (Latest)

Get Node Metrics (Historical)

curl "{supervisor_url}/deployments/{deployment_id}/nodes/{node_id}/metrics/iggy?page=1&results=10&from=2026-01-01T00:00:00Z&to=2026-02-01T00:00:00Z" \
-H "ld-api-key: YOUR_API_KEY"

Get Deployment Network Throughput

curl "{supervisor_url}/deployments/{deployment_id}/metrics/throughput?from=2026-10-13T09:00:00Z&to=2026-10-13T10:00:00Z&interval=30s" \
-H "ld-api-key: YOUR_API_KEY"

The figure is all network traffic of the deployment's nodes on every interface: client traffic, replication between nodes, LaserData traffic, and traffic between processes on a node. It is not message throughput. Buckets are aligned to multiples of interval since the Unix epoch, so from rounds down and to rounds up. The window starts no earlier than the deployment's metric retention and ends with the bucket that holds the current time.

The reply has the aligned from and to in microseconds since the epoch, interval in the same notation, such as 5m or 1day, nodes_expected, the current node count, and points. Each point has timestamp, the start of its bucket, nodes_reporting, rx_bytes_per_second, and tx_bytes_per_second.

Each node's rate comes from consecutive samples of that node, divided by the real time between them, and an interval counts toward the bucket of its later sample. Samples more than 60 seconds apart are not paired. A counter that decreases, for example after a node restart that lost its saved totals, starts a new baseline instead of producing a negative rate. The deployment rate of a bucket is the sum of the node rates. A point is complete when nodes_reporting reaches nodes_expected. A point with fewer nodes is a partial sum, and a point without any reporting node has null rates, which differs from a measured 0. Free deployments on shared hosts return no points, because their nodes report no network counters of their own.

Three limits keep each request small: interval from 10s to 1d, at most 1440 buckets, and at most 31 days between the rounded from and to. For example, 31 days at 1h gives 744 buckets, one day at 1m gives 1440, and 31 days at 30s is refused for its 89,280 buckets.

A from, to or interval that cannot be read, such as 30 without a unit, returns 400. A window that does not start before it ends or spans more than 31 days returns invalid_metrics_window. A readable interval outside whole seconds from 10s to 1d returns invalid_metrics_interval, and more than 1440 buckets return too_many_metrics_points.

Readiness

Readiness reports observed_at, iggy_ready, last_probe_at, and serving. iggy_ready and last_probe_at can be unknown. serving is true only when every readiness check on the node passes. A running process or recent heartbeat alone does not prove readiness to serve.

The reply has expected_nodes, serving_nodes, quorum_available and all_nodes_serving. quorum_available is true when the serving nodes reach the cluster's view-change quorum: 1 of one node, 2 of two, and n - min(ceil(n / 2), 3) + 1 otherwise, which is more than half up to six nodes. Each node has readiness with observed_at, iggy_ready, last_probe_at and serving (null until the node reports), and runtimes for iggy, connectors and connector:{id} with version, running and healthy. A connector:{id} runtime also has connector with kind (source or sink), state (starting, running, stopping, stopped or error), errors, the number of errors since the connectors runtime started, key and name, and last_error with message and occurred_at. key and name need deployment:connectors:read, and message needs deployment:config:read, otherwise they are null. The message is at most 512 bytes. URLs keep only their scheme and host, and Bearer and Basic credentials and the values of secret settings such as password or token are masked. operation is the operation that owns the deployment, with kind, status, phase (preparing, updating_nodes, finishing or rolling_back) and reason. reason says why a paused operation stopped: timeout, unknown_cloud_error or internal_error. It is null while the operation is not paused or when no reason is known. The request needs deployment:telemetry:read. See Monitoring.

Heartbeats

Heartbeats report recent liveness. Use them to track uptime and detect restarts.

Get Deployment Heartbeats (Latest)

curl {supervisor_url}/deployments/{deployment_id}/heartbeats \
-H "ld-api-key: YOUR_API_KEY"

Get Node Heartbeats (Latest)

Get Node Heartbeats (Historical)

curl "{supervisor_url}/deployments/{deployment_id}/nodes/{node_id}/heartbeats/iggy?page=1&results=10&from=2026-01-01T00:00:00Z&to=2026-02-01T00:00:00Z" \
-H "ld-api-key: YOUR_API_KEY"

Logs

Get Deployment Logs

curl "{supervisor_url}/deployments/{deployment_id}/logs/iggy?page=1&results=10&level=any&message=*&from=2026-01-01T00:00:00Z&to=2026-02-01T00:00:00Z" \
-H "ld-api-key: YOUR_API_KEY"

You can also send logs to an OpenTelemetry-compatible endpoint. See Monitoring for configuration.