Kubernetes probes should be specific: startup checks if initialization is complete, readiness assesses if an instance can handle traffic, and liveness determines if the process is stuck. Startup probes allow extra time for initialization tasks like compiling pricing rules before other probes become active. Readiness probes verify that an instance can serve the active rule and necessary dependency states, removing the pod from service endpoints if failed. Liveness probes check for unrecoverable process issues, triggering container restarts when a problem is detected. This separation prevents unrelated dependency failures from causing unnecessary container restarts, which can amplify problems. For a property-management API, readiness ensures an instance is ready to serve a specific pricing rule, protecting tenants from inconsistent quotes. Startup probes are essential when initialization takes longer than the liveness budget, preventing premature liveness or readiness checks. Readiness probes are chosen for conditions that stop new traffic but can recover without a restart, like lacking a rule snapshot. Liveness probes are reserved for issues a restart can fix, such as an unresponsive event loop, and should be narrow to avoid unnecessary restarts. Health endpoints should use distinct paths for each probe type, avoid network calls in liveness checks, and return minimal status codes.