If every restart stalls at WAL replay, determine whether the same work is being repeated before deleting data. A living process that is not ready is operationally different from one killed by OOM and restarted from the beginning.
Reconstruct one startup in time order
Build a timeline of process start, WAL replay progress, readiness changes and termination. Compare process RSS with container or cgroup memory limits and OOM evidence. If all you know is “not ready, then restarted,” first check whether a liveness probe or supervisor interrupted a living replay. A memory increase is a later decision.
promtool --version
promtool tsdb list --help
promtool tsdb analyze --helpStart with the installed version’s help. The WAL and compacted blocks in the storage documentation are different artifacts. A block analysis from promtool tsdb analyze does not measure every series currently in the WAL or peak replay memory. Do not run a large analysis alongside recovery on a 1 GB production host.
Choose the next action from combined evidence
If progress continues without termination, observe recovery time. If the same stage ends with corroborating OOM evidence, investigate limits, concurrent work and recent cardinality growth. For a repeated corruption error, preserve a backup or copy before using the version-specific recovery procedure. None of these observations makes deleting the WAL an appropriate first step.
Recovery assessment includes fresh scrape success and historical queries, not readiness alone. This is an analysis of what each evidence source can establish; no specific capacity, replay duration or production recovery success was measured.