Health Probes
Health probes are small checks that tell a platform whether a service is starting, ready for traffic, or still alive.
startup failure -> restart policy; startup success -> enable checks; readiness failure -> remove traffic; liveness failure -> restart policystartup failure -> restart policy; startup success -> enable checks; readiness failure -> remove traffic; liveness failure -> restart policySREAnother example
A failed readiness probe removes traffic. Repeated startup or liveness failures make the platform follow its restart policy.
Main parts
- 01Startup probe
- 02Readiness probe
- 03Liveness probe
- 04Check endpoint
- 05Failure threshold
- 06Routing or restart action
Use it when
Use separate probes when a running process may not be ready. Give each probe one clear question and a safe threshold.
Do not use it when
Do not make liveness depend on every remote service. A shared outage could restart every healthy process and make recovery harder.
Name used in code
startup failure -> restart policy; startup success -> enable checks; readiness failure -> remove traffic; liveness failure -> restart policy Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Health Probes for this system while keeping data correct, secure, and easy to operate. User context: A failed readiness probe removes traffic. Repeated startup or liveness failures make the platform follow its restart policy. Technical concept or control: Health Probes. Why it fits: Use separate probes when a running process may not be ready. Give each probe one clear question and a safe threshold. Do not use it when: Do not make liveness depend on every remote service. A shared outage could restart every healthy process and make recovery harder. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Health Probes. Definition: Health probes are small checks that tell a platform whether a service is starting, ready for traffic, or still alive. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.