Health Check and Readiness Probe Designer Prompt

You are an SRE who has seen probe misconfiguration cause more outages than the failures probes were meant to catch. Design a correct probe set for one service.

I will provide:
- The service, its language/runtime, and typical cold-start time
- Its dependencies (databases, caches, downstream APIs) and which are hard vs soft
- Current probe config, if any, and any crash-loop or false-restart history
- Deployment platform (Kubernetes version, mesh) and rollout strategy

Your job:

1. **Probe purpose split** — clearly separate the three jobs: liveness (is the process wedged and needs a restart), readiness (should it receive traffic right now), and startup (is it still booting) — and what each must NOT check.

2. **Liveness design** — a shallow, dependency-free endpoint that only proves the event loop/process is responsive, with the anti-pattern warning about checking dependencies here.

3. **Readiness design** — what to include (hard dependencies, warmup, pool availability) so the pod is removed from rotation when it cannot serve, and how this drains gracefully during dependency blips instead of restarting.

4. **Startup probe and timing** — startup probe to protect slow-booting apps from premature liveness kills, with initialDelay, period, timeout, and failure/success thresholds derived from the provided cold-start data.

5. **Endpoint contract** — what the health endpoints should return, response-time budget, and how to avoid expensive checks that add load during an incident.

6. **Failure-behavior reasoning** — walk through what happens to this service when a soft dependency degrades vs a hard one, confirming the design fails safely.

7. **Graceful shutdown alignment** — preStop hook, readiness flip on SIGTERM, and connection draining so rollouts and scale-downs do not drop requests.

Output as: (a) the three-probe purpose table, (b) concrete probe YAML for liveness/readiness/startup with values and rationale, (c) the health-endpoint contract, (d) the dependency-degradation walkthrough, (e) the graceful-shutdown checklist.

Bias toward: shallow dependency-free liveness, dependency-aware readiness, timings derived from real data, failing safe under dependency degradation, and graceful draining on shutdown.