Separate liveness and readiness checks

Liveness answers whether the process should restart. Readiness answers whether it should receive traffic. Conflating them can create restart storms during a dependency outage.

Simulate three states

The integration lab evaluates healthy, database-down and process-dead fixtures.

from integration_cases import probes_case

result = probes_case()
assert result["rows"][1]["liveness"] == 200
assert result["rows"][1]["readiness"] == 503
assert result["dependency_outage_restart"] is False
assert result["dependency_outage_removed_from_traffic"] is True
assert result["platform_executed"] is False

Use startup probes for slow initialization, liveness for unrecoverable process failure and readiness for dependency, migration or overload conditions. Keep each check bounded and cheap. A readiness failure should allow recovery without losing in-memory work; a liveness restart needs grace and idempotent recovery.

Test thresholds to avoid flapping and cascading restarts. Monitor probe outcomes with service errors so a permanently unready deployment alerts the owner.

The FDE for Freshers course connects probe semantics to cloud reliability.

Exercise

Implement three endpoints/states in a local service and write a table of platform action for each. Inject database failure and verify no restart trigger.

Continue learning

This article is part of the FDE integration and deployment foundations sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Deploy a service with a health endpoint.
• Continue with Add structured request logs and correlation IDs.

Reference: Kubernetes liveness, readiness and startup probes.