Decide whether the check measures process life, readiness for traffic or a complete synthetic customer journey. Identify how the monitor reacts to failure.

1. Use a lightweight liveness check for basic process responsiveness. Avoid making every transient external outage trigger an unnecessary process restart.

2. Use readiness checks for dependencies required before serving traffic. Set short timeouts and keep the response free of credentials or customer data.

3. Add a separate controlled synthetic workflow when a simple endpoint cannot represent the service customers use. Use safe test identities and actions.

4. Set monitoring frequency, retry thresholds and alert ownership to fit the service. Avoid checks that overload the dependency they are monitoring.

5. Test controlled failures in staging and verify the intended alert, traffic-removal or recovery behavior.

For an application with a required database, define two monitoring purposes before writing the endpoints. The following test plan uses illustrative paths and statuses. It avoids making a brief database outage trigger a continuous cycle of application restarts.

GET /health/live   -> 200 when the web process can respond
GET /health/ready  -> 200 when required dependencies are usable
GET /health/ready  -> 503 during a required dependency failure

In staging, make the database temporarily unavailable through the approved test setup. Liveness should still describe the process, while readiness should fail within a short timeout. Return a small status message and keep the dependency exception private. Choose monitor frequency and failure thresholds that do not create their own connection pressure.

Expected result: The load balancer or operator receives the intended signal, and the service returns to ready after recovery. A separate synthetic login test covers customer behaviour that these small endpoints cannot prove.

Confirm the check becomes unhealthy for the failure it is meant to detect and returns to healthy after recovery. Compare it with an ordinary user workflow.

A permanently green endpoint may be too shallow, while an overly deep liveness probe can cause restart loops during a dependency outage. Separate those purposes.

• Checking Laravel health without exposing private data
• Protecting FastAPI documentation and health endpoints
• Verifying a deployment with application smoke checks
• Choosing a database connection pool size

• Kubernetes probe concepts
• Express health checks

• Express health checks and graceful shutdown