Install the DALP Helm chart

Run helm upgrade with a --timeout sized to your deployment's worst case, such as 30 to 40 minutes, and adjust for your cluster. Helm's own default wait is 5 minutes. A timeout abort does not roll back completed steps by itself, so check helm history and the workload status before you retry. progressDeadlineSeconds is 1500 seconds (25 minutes) on both dapi and dapp, above the Kubernetes default of 600. A single surge pod can spend up to its boot budget plus relaunch headroom before /readyz reports ready, so a tighter number needs its own margin. On the Kubernetes default of 600 seconds, dapp would trip before the PgBouncer pooler it waits on, which needs up to 900, and that reads as a Console failure when the fault is the pooler. dapp's 1500 seconds outlasts it. The API fleets roll with maxSurge: 1 and maxUnavailable: 0, one pod at a time, so a tight timeout can fire before the last workload reports ready. A tight scheduler pool adds its own stall: see overprovisioning.enabled.

Kubernetes' readiness and startup probes differ by workload in what they check and how long they wait, so confirm which one is failing with kubectl describe pod before assuming Postgres is the problem. dapi's /readyz probes Postgres through a dedicated health session every 15 seconds. The probe has a 10-second timeout and allows three failures. An unavailable database removes the pod from service after roughly 45 seconds, or up to about 55 seconds including reporting lag. dapi's startup probe answers on /healthz instead, with its own 180-second boot budget. dapp's startup and readiness probes both answer on /readyz. Its liveness probe answers on /healthz. The startup probe budgets 300 seconds (5 minutes) for slow first-boot SSR and SDK warmup, and only once that clears does the readiness probe start applying its own 3-second, process-only budget. A pod stuck in that 300-second startup window looks identical to a hung readiness probe in kubectl get pods output, so check which probe is failing before assuming either.

dapi renders each role as its own Deployment: the /api/v1 and /api/v2 fleets, a runner, a scheduler, and an indexer with a separate rebuild Deployment. The API fleets and the runner have their own HorizontalPodAutoscaler. The indexer, its rebuild pods and the scheduler run a fixed replica count. The API fleets roll maxSurge: 1 and maxUnavailable: 0, the same one-at-a-time pattern as dapp. The indexer rolls the other way, maxUnavailable: 1 and maxSurge: 0, and holds a replacement back for a 90-second minReadySeconds before it counts as ready. The runner and the scheduler use the Recreate strategy, so their old pods stop before the new ones start. The indexer and the runner each have a PodDisruptionBudget that keeps at least one pod up. Expect the indexer, runner and scheduler to take an old pod down before a new one is ready. This protects capacity in those roles and is not a stuck rollout.

Redis does not gate startup. Cache and notification connections are supervised per pod, so bringing the platform up before Redis is ready is supported: pods serve from their in-process cache and reconnect on a jittered exponential backoff capped at 30 seconds, with no attempt limit. Reconnection checks that Redis is serving requests rather than only accepting connections, so an endpoint still loading a snapshot is retried instead of treated as healthy. While disconnected, cached reads stay correct but remain private to each pod, and change notifications use each listener's own reconcile interval. Watch dalp_redis_client_unavailable_seconds, labelled per redis_role, so you can tell which of the two clients, cache or notifications, is the one that dropped. The RedisClientLatchedOffline alert (severity warning) confirms roughly six minutes into a sustained outage, identifying a pod that has not recovered from more than a brief restart.

The Ledger Data indexer learns about new blocks from a standard newHeads subscription on the chain node's WebSocket. It sends eth_blockNumber on the same socket every 10 seconds. It reconnects when no reply arrives, or when the reply is more than three blocks past the last head the subscription delivered. It reads the head over HTTP on every new subscription, so blocks mined during an outage are indexed after the reconnect. A connection-state gauge reports three values (connected, disconnected, or circuit broken), and a separate dalp_didx_ws_unavailable_seconds series tracks how long the socket has been down, because the state gauge alone cannot distinguish a two-second blip from a standing outage. The IndexerWebSocketHeadLatchedOffline alert (severity warning) confirms roughly six minutes into a sustained outage, keyed per network, long enough that an ordinary reconnect never pages. Live indexing does not advance while the socket is down, because no poll runs beside the subscription. Once the socket reconnects, the indexer reads the current head and indexes every block it missed.