System

Public base URL of the rlp-analytics spending service (PLAN-ANALYTICS-SERVICE.md), set by the operator and trimmed of a trailing slash. null when unset — or when the value is not an http(s)://host[:port][/path] base (see analytics_base_url) — the dashboard then shows no spending analytics. The URL itself is published (unlike the billing service's) because the browser calls rlp-analytics directly, with its own bearer; the dashboard passes it through safeUrl like toolbox_url.

Public base URL of this API when the deployment advertises one.

Whether the member-facing billing surface is wired (PLAN-BILLING-WALLET.md). A boolean rather than the URL because the browser never talks to rlp-billing directly (D1) — it only needs to know whether to render Billing.

Full commit SHA this API was built from; unknown when unstamped.

RFC 3339 UTC instant the build ran, for example 2026-10-02T14:03:11Z; unknown when unstamped.

Public documentation site URL for this deployment.

Toolbox proxy base URL the browser should use. A deployment-specific browser override wins over the general proxy URL when both are set.

Platform version this API was built as (PLAN-BUILD-IDENTITY.md): the latest published release, for example 2.0.0-alpha.1; 0.0.0-dev for an unstamped build. The same value GET /health reports.

Full commit SHA this binary was built from; unknown when unstamped.

RFC 3339 UTC instant the build ran; unknown when unstamped.

Platform version this binary was built as (the latest published release); 0.0.0-dev for an unstamped build.

Total creates the create-expiry reaper (events::maintenance) has ever deleted before they reached running. Historical field name kept so the health surface stays stable; a nonzero rate means creates are timing out before becoming live right now.

ok | unhealthy (migration ledger missing or empty) — the same DB/migration probe /health runs, now also covered here (found by review, 2026-08-25: previously absent). Draining is reported only in the outer status field, never here — this field reflects the DB probe alone, so it stays ok even while draining if the DB itself is fine (cubic review, 2026-08-27: the field never actually emits a "degraded" value). Probed concurrently with nats (PLAN-HEALTH-LIVENESS.md) — neither should wait on the other, and a wedged one must not delay reporting the other's real state.

Fleet-wide JetStream consumer health, summed across every consumer on the JOBS stream (2026-08-27): distinguishes "queue is deep because load is high" from "queue is deep because runners have stopped acking" — no other signal here made that distinction before.

ok when JetStream answered the bounded $JS.API.INFO probe.

OTel pipeline state.

Reaper ticks (cumulative, this process) on which the herd guard refused to mark runners lost because EVERY online runner was stale at once — an observer/transport outage signature, not fleet death (issue #1205). Nonzero and climbing means the api can hear NATS but no runner heartbeat is arriving: check the bus, the runners' NATS connectivity, and the runner herd-guard threshold configuration.

Whether the reaper is currently allowed to mark runners lost from last_seen_at staleness (issue #1205): unbound (the heartbeat lane is not consuming — nothing refreshes last_seen_at), settling (it (re)bound less than one stale window ago; lost-marking is suppressed until the runners have heartbeated through the new subscription) or armed. A process that stays unbound/settling for minutes has a wedged or flapping runner-event lane.

Rate-limit Redis state (PLAN-AUTH-RATE-LIMITS.md §2.6): ok | degraded (PING failed/timed out — brute-force protection is silently off, fail-open) | unconfigured (rate-limit storage disabled on this deployment). Never flips the overall status — the limiter fails open by design.

Managed streams whose retention config drifted from desired. Non-empty is the alarm that was missing during both retention-drift incidents.

draining (publish-watchdog trip) | unhealthy (DB/migration-ledger probe failed) | degraded (NATS probe failed) | warn (retention alarms present) | ok — checked in that priority order, draining and unhealthy first since those matter most for a deploy decision.

Present only on a 503 (draining / bad DB / degraded NATS), same as every ApiError body — this endpoint's success/error bodies share one documented shape (DeepHealth) that ApiError's generic {"error": "..."} envelope can't carry without dropping the rest of these fields (api/AGENTS.md's ApiError section documents this as the one narrow exception), so the trace ID is attached here directly via the same helper error::envelope uses rather than through ApiError.