{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/health-check","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/health-check/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/health-check/"},"term":{"en":"Health check","da":"Sundhedstjek (health check)"},"aka":{"en":[],"da":["health check"]},"domain":["platform"],"cluster":"observability","layer":"observability","status":"current","summary":{"en":"A small automatic test, repeated every few seconds, that asks a running service whether it is alive and able to answer.","da":"En lille automatisk test, gentaget med få sekunders mellemrum, der spørger en kørende tjeneste, om den lever og kan svare."},"body":{"formal":{"en":"A regular request, often to a fixed web address or port, whose answer tells the platform whether a copy of a service is running and ready for work; copies that fail are restarted or taken out of the group that receives traffic.","da":"En fast, gentaget forespørgsel, ofte til en bestemt webadresse eller port, hvis svar fortæller platformen, om en kopi af en tjeneste kører og er klar til arbejde; kopier, der fejler, genstartes eller tages ud af den gruppe, der modtager trafik."},"plain":{"en":"Like a lifeguard who calls out to each swimmer now and then; anyone who does not answer gets pulled out of the water.","da":"Som en livredder, der råber til hver svømmer en gang imellem; den, der ikke svarer, bliver hevet op af vandet."},"inPractice":{"en":"On the first day of term, Kubernetes checks each copy of a school portal's login service every ten seconds; one copy runs out of memory and stops answering, so it is restarted and gets no users until it answers again.","da":"På første skoledag tjekker Kubernetes hver kopi af skoleportalens login-tjeneste hvert tiende sekund; én kopi løber tør for hukommelse og holder op med at svare, så den genstartes og får ingen brugere, før den svarer igen."},"whyItMatters":{"en":"Machines fail all the time; health checks let the platform send traffic around a broken copy within seconds, before users notice and before anyone is woken up.","da":"Maskiner fejler hele tiden; sundhedstjek lader platformen lede trafikken uden om en defekt kopi på få sekunder, før brugerne mærker det, og før nogen bliver vækket."}},"deepDive":{"en":"Health checks answer different questions depending on who asks. Kubernetes separates them into three probe types run by the kubelet. A liveness probe asks whether the process is stuck beyond recovery; after failureThreshold consecutive failures the container is killed and restarted according to the pod's restart policy. A readiness probe asks whether the instance should receive traffic now; failure marks the pod not ready and removes its address from the Service's EndpointSlices without restarting anything. A startup probe, when defined, suspends the other two until it succeeds, so slow-initialising applications are not killed by liveness checks during boot. Probes can be httpGet (any status from 200 up to 399 counts as success), tcpSocket, exec (exit code 0) or grpc using the standard gRPC Health Checking Protocol, stable since Kubernetes 1.27. Defaults are initialDelaySeconds 0, periodSeconds 10, timeoutSeconds 1, successThreshold 1 and failureThreshold 3.\n\nLoad balancers run their own checks independently: cloud load balancers, HAProxy and Envoy probe backends at an interval and use separate healthy and unhealthy thresholds, which act as hysteresis against flapping. Envoy and similar proxies add passive health checking (outlier detection), ejecting a backend after a run of real request failures without any synthetic probe.\n\nThe most common design error is a deep liveness check that calls the database or downstream services. When the shared dependency degrades, every replica fails liveness at once and Kubernetes restarts the whole fleet, turning a partial outage into a total one and adding cold-start load. The usual guidance is to keep liveness shallow (the process can serve an HTTP request and its event loop is not deadlocked), let readiness reflect whether the instance itself can serve useful work, and handle dependency failures through timeouts, circuit breakers and degraded responses rather than restarts. Some applications also fail readiness deliberately on receiving SIGTERM while continuing to serve for a few seconds, so that load balancers which learn about endpoint changes with a delay stop routing to them before the process exits.\n\nOther pitfalls are timeouts shorter than garbage-collection pauses, check endpoints that are expensive or unauthenticated yet expose version and dependency details, and treating a green health check as proof of correctness: a service can answer 200 on /healthz while returning wrong data. External synthetic monitoring, which exercises a real user journey from outside the network, complements internal probes, and health-check results feed monitoring and alerting but are not a substitute for symptom-based SLO alerts.","da":"Sundhedstjek besvarer forskellige spørgsmål afhængigt af, hvem der spørger. Kubernetes deler dem op i tre probetyper, som kubelet kører. En liveness-probe spørger, om processen er gået i hårdknude uden mulighed for at komme sig; efter failureThreshold fejl i træk bliver containeren dræbt og genstartet efter pod'ens restart policy. En readiness-probe spørger, om instansen skal modtage trafik lige nu; fejl markerer pod'en som ikke klar og fjerner dens adresse fra Servicens EndpointSlices uden at genstarte noget. En startup-probe sætter, når den er defineret, de to andre på pause, indtil den lykkes, så applikationer med lang opstart ikke bliver dræbt af liveness-tjek under opstarten. Prober kan være httpGet (enhver statuskode fra 200 til og med 399 tæller som succes), tcpSocket, exec (exitkode 0) eller grpc via standardprotokollen gRPC Health Checking, stabil siden Kubernetes 1.27. Standardværdierne er initialDelaySeconds 0, periodSeconds 10, timeoutSeconds 1, successThreshold 1 og failureThreshold 3.\n\nLoadbalancere kører deres egne tjek uafhængigt heraf: cloud-loadbalancere, HAProxy og Envoy prober backends med et fast interval og bruger separate tærskler for sund og usund, som virker som hysterese mod flapping. Envoy og lignende proxyer tilføjer passiv sundhedskontrol (outlier detection), hvor en backend fjernes efter en række reelle fejlede forespørgsler uden nogen syntetisk probe.\n\nDen mest udbredte designfejl er et dybt liveness-tjek, der kalder databasen eller andre tjenester. Når den fælles afhængighed svigter, fejler alle replikaer liveness samtidig, og Kubernetes genstarter hele flåden, så et delvist nedbrud bliver totalt og suppleres af kold-start-belastning. Den gængse anbefaling er at holde liveness overfladisk (processen kan besvare en HTTP-forespørgsel, og dens event loop er ikke låst), lade readiness afspejle, om instansen selv kan udføre nyttigt arbejde, og håndtere fejl i afhængigheder med timeouts, circuit breakers og nedgraderede svar frem for genstarter. Nogle applikationer lader også bevidst readiness fejle, når de modtager SIGTERM, men fortsætter med at betjene forespørgsler i nogle sekunder, så loadbalancere, der først opdager ændrede endpoints med forsinkelse, holder op med at sende trafik, før processen stopper.\n\nAndre faldgruber er timeouts, der er kortere end pauser fra garbage collection, tjek-endpoints, der er dyre eller uden autentificering og samtidig afslører version og afhængigheder, og at opfatte et grønt sundhedstjek som bevis på korrekthed: en tjeneste kan svare 200 på /healthz og samtidig returnere forkerte data. Ekstern syntetisk overvågning, der gennemløber en rigtig brugerrejse udefra, supplerer de interne prober, og resultaterne af sundhedstjek fødes ind i overvågning og alarmering, men erstatter ikke symptombaserede SLO-alarmer."},"edges":[{"type":"requires","to":"cs/service","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/kubernetes","why":{"en":"Kubernetes runs health checks on every container and uses the answers to restart it or hold back traffic.","da":"Kubernetes kører sundhedstjek på hver container og bruger svarene til at genstarte den eller holde trafik tilbage."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"platform/monitoring","confidence":"high","strength":"normal"}],"depth":1,"sources":[{"title":"Kubernetes Documentation - Configure Liveness, Readiness and Startup Probes","url":"https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/","tier":"official-doc","publisher":"The Kubernetes Authors"},{"title":"Google SRE book - Chapter 20, Load Balancing in the Datacenter","url":"https://sre.google/sre-book/load-balancing-datacenter/","tier":"reference","publisher":"Google"}],"draft":true}