A six-pod food-delivery backend starts cascading pod restarts whenever its Postgres instance gets slow, even though the application code is healthy. The team's /health endpoint runs a database query and is wired to the liveness probe. Walk me through what is happening and how you would fix it.

1. Separate the two questions being asked: liveness answers 'is this process alive', readiness answers 'can this pod serve traffic right now'. 2. Identify the failure mode: the kubelet polls /health every few seconds, the DB call inside it times out, liveness fails, the kubelet restarts the container, and the restart storm adds load to the already-slow database. 3. Move all dependency checks (database, cache, downstream services) to a separate /ready endpoint bound to the readiness probe. 4. Make the liveness endpoint check only in-process health with no network calls. 5. Set failureThreshold and periodSeconds so a transient blip does not trigger a restart. 6. Add a startup probe so slow boots are not misread as liveness failures. 7. Note the resulting behaviour: a slow database now removes pods from the Service endpoints instead of killing them, so they recover without a restart.