Verify Server Readiness After a Restart
A 6-step recipe with Prometheus. We can help you get access.
Recipe · 6 steps
Verify Server Readiness After a Restart
with Prometheus
Post-restart verification of health, readiness, WAL replay, build, and flags.
- Liveness check. A 200 means the process is up and not wedged; it says nothing about whether the server can answer queries yet.
- Readiness check. A 503 here on a freshly restarted server is expected and normally means WAL replay is still in progress, which the next step quantifies.
- Read WAL replay progress. The current and max segment numbers turn "not ready yet" into an actual estimate of how much longer recovery will take.
- Confirm the running binary is the build the deployment intended. The revision is what settles a disagreement about whether a rollout actually landed on this instance.
- Read the command-line flags in force. Retention, storage paths, and the enable-lifecycle and enable-admin-api toggles are all set here, and a restart is exactly when one of them silently changes.
- Read the runtime properties to confirm the server came back with its configuration successfully loaded and to record the new start time.
What you'll need to have ready
- expectedVersion: Optional version string the deployment expected to roll out, for comparison against the reported build info.
For your developer
Arazzo workflow prometheus:server-restart-readiness, 6 operations: checkHealth → checkReady → getWalReplayStatus → getBuildInfo → getFlags → getRuntimeInfo. Specs on APIs.io.