MicroProfile Health exposes application status through HTTP health-check endpoints. Monitoring tools can call these endpoints periodically, while Kubernetes can use them to restart unhealthy pods or stop sending traffic until an application is ready. section 10.2 section 10.7
In Quarkus, SmallRye Health provides the implementation through the smallrye-health extension. Quarkus supplies some checks automatically, including a readiness check when an application uses a data source, and supports custom checks through the HealthCheck interface. section 10.2 section 10.8
Choose a health-check category according to the operational question it answers:
- Liveness indicates whether the application can continue running; failure represents a problem such as running out of memory or a deadlock, so Kubernetes may restart the pod. section 10.2 section 10.8
- Readiness indicates whether the application can receive traffic; failure can hold traffic when a required database connection is unavailable or active work exceeds a threshold. section 10.2 section 10.8
- Startup indicates that initialization has completed. After it passes once, liveness and readiness checks take over. section 10.2 section 10.8
- Wellness reports less serious problems that do not require immediate automated action, while custom health groups organize application-specific checks. section 10.8
Kubernetes-facing service health
A service depending on a database can expose readiness that fails when the database connection is unavailable. Kubernetes then withholds traffic, while a separate liveness failure can trigger a pod restart. During development, Quarkus Dev UI can show the current health-check status. section 10.2 section 10.8
