Health Checks That Actually Work: Liveness vs Readiness vs Startup Probes
A crash loop isn't always a bug; sometimes it's the orchestrator restarting a service before it's actually capable of serving traffic. What We're Building We are defining three distinct health chec...

Source: DEV Community
A crash loop isn't always a bug; sometimes it's the orchestrator restarting a service before it's actually capable of serving traffic. What We're Building We are defining three distinct health check strategies for a Go-based microservice running in a container orchestration environment. The scope covers implementing HTTP endpoints and external checks that signal the scheduler when the application is initializing, when it is safe to receive traffic, and when it requires a restart. We will define configuration structures that separate initialization logic from traffic readiness logic, ensuring the system recovers gracefully from deadlocks without dropping requests. Step 1 — Define the Probe Lifecycle The core concept is treating health checks as state transitions rather than a single boolean. We must separate the duration required to become ready from the duration required to recover from a failure. type ProbeConfig struct { Startup Probe `json:"startup"` Readiness Probe `json:"readiness