[{"data":1,"prerenderedAt":534},["ShallowReactive",2],{"\u002Fblog\u002Fkubernetes-ingress-monitoring-vs-readiness-liveness-probes":3},{"id":4,"title":5,"author":6,"body":8,"category":512,"date":513,"description":514,"extension":515,"faq":516,"howTo":526,"image":526,"lastUpdated":513,"meta":527,"navigation":528,"path":529,"readingTime":530,"seo":531,"stem":532,"__hash__":533},"blog\u002Fblog\u002Fkubernetes-ingress-monitoring-vs-readiness-liveness-probes.md","Kubernetes Ingress Monitoring vs Readiness and Liveness Probes: What to Use and When",{"name":7},"Theo Cummings",{"type":9,"value":10,"toc":490},"minimark",[11,15,20,88,91,95,98,117,120,124,127,188,197,201,205,208,223,226,230,233,236,250,253,257,260,263,274,281,285,288,302,305,309,314,325,329,340,344,347,351,411,418,422,425,428,431,435,466,470,487],[12,13,14],"p",{},"Kubernetes readiness and liveness probes tell you if containers should receive traffic or restart. They do not tell you if users can reach your app through ingress. Ingress monitoring closes that gap by testing real entry routes, DNS, TLS, and region-specific access paths.",[16,17,19],"h2",{"id":18},"short-answer-probes-and-ingress-checks-solve-different-problems","Short answer: probes and ingress checks solve different problems",[21,22,23,42],"table",{},[24,25,26],"thead",{},[27,28,29,33,36,39],"tr",{},[30,31,32],"th",{},"Signal",[30,34,35],{},"Scope",[30,37,38],{},"Detects",[30,40,41],{},"Misses",[43,44,45,60,74],"tbody",{},[27,46,47,51,54,57],{},[48,49,50],"td",{},"Liveness probe",[48,52,53],{},"Container process health",[48,55,56],{},"Deadlock, crash, stuck process",[48,58,59],{},"DNS, TLS, ingress, external routing",[27,61,62,65,68,71],{},[48,63,64],{},"Readiness probe",[48,66,67],{},"Pod traffic eligibility",[48,69,70],{},"App warm-up, dependency readiness",[48,72,73],{},"External reachability, WAF\u002FCDN failures",[27,75,76,79,82,85],{},[48,77,78],{},"Ingress synthetic check",[48,80,81],{},"User-facing entry path",[48,83,84],{},"DNS, TLS, LB, ingress controller, app response",[48,86,87],{},"Deep internal cause without extra telemetry",[12,89,90],{},"This is why strong teams run both.",[16,92,94],{"id":93},"where-probe-only-strategies-fail","Where probe-only strategies fail",[12,96,97],{},"Probe-only monitoring fails in common production incidents:",[99,100,101,105,108,111,114],"ul",{},[102,103,104],"li",{},"Ingress controller misconfiguration returns 502 while pods are ready",[102,106,107],{},"TLS certificate expires on public endpoint while liveness checks pass",[102,109,110],{},"External DNS points to wrong load balancer target",[102,112,113],{},"Cloud edge path fails in one region only",[102,115,116],{},"OAuth callback path breaks after ingress rewrite change",[12,118,119],{},"Each issue causes user downtime with healthy pod probes.",[16,121,123],{"id":122},"layered-kubernetes-uptime-model","Layered Kubernetes uptime model",[12,125,126],{},"Use four layers.",[21,128,129,142],{},[24,130,131],{},[27,132,133,136,139],{},[30,134,135],{},"Layer",[30,137,138],{},"Tooling",[30,140,141],{},"Goal",[43,143,144,155,166,177],{},[27,145,146,149,152],{},[48,147,148],{},"Layer 1: Probe health",[48,150,151],{},"Kubernetes readiness and liveness probes",[48,153,154],{},"Keep workloads stable inside cluster",[27,156,157,160,163],{},[48,158,159],{},"Layer 2: Ingress endpoint checks",[48,161,162],{},"External HTTP synthetic checks",[48,164,165],{},"Detect user-path failures fast",[27,167,168,171,174],{},[48,169,170],{},"Layer 3: Transaction checks",[48,172,173],{},"Browser or API flow checks",[48,175,176],{},"Validate login, checkout, and critical journeys",[27,178,179,182,185],{},[48,180,181],{},"Layer 4: Dependency checks",[48,183,184],{},"DNS, SSL, third-party API, heartbeat",[48,186,187],{},"Catch hidden upstream and async failures",[12,189,190,191,196],{},"For tool options, see ",[192,193,195],"a",{"href":194},"\u002Fblog\u002Fbest-kubernetes-uptime-monitoring-tools","best Kubernetes uptime monitoring tools",".",[16,198,200],{"id":199},"practical-setup-for-ingress-uptime-monitoring","Practical setup for ingress uptime monitoring",[16,202,204],{"id":203},"step-1-select-ingress-endpoints-by-business-impact","Step 1: Select ingress endpoints by business impact",[12,206,207],{},"Monitor these first:",[209,210,211,214,217,220],"ol",{},[102,212,213],{},"Primary app hostname route",[102,215,216],{},"Login callback route",[102,218,219],{},"Core API route behind ingress",[102,221,222],{},"Checkout or billing route",[12,224,225],{},"Use 30 to 60 second intervals for P1 paths.",[16,227,229],{"id":228},"step-2-add-response-assertions","Step 2: Add response assertions",[12,231,232],{},"Do not stop at HTTP 200.",[12,234,235],{},"Validate:",[99,237,238,241,244,247],{},[102,239,240],{},"Status code",[102,242,243],{},"Body marker or JSON schema key",[102,245,246],{},"Latency thresholds",[102,248,249],{},"Redirect destination for auth flows",[12,251,252],{},"This prevents soft-failure blind spots.",[16,254,256],{"id":255},"step-3-add-multi-region-checks","Step 3: Add multi-region checks",[12,258,259],{},"Ingress issues can be regional.",[12,261,262],{},"Run probes from US, EU, and AP regions and alert on quorum rules:",[99,264,265,268,271],{},[102,266,267],{},"3 of 3 fail: critical outage",[102,269,270],{},"2 of 3 fail: regional degradation",[102,272,273],{},"1 of 3 fail: investigate network path, no page yet",[12,275,276,277,196],{},"See ",[192,278,280],{"href":279},"\u002Fblog\u002Fsingle-region-monitoring-is-broken","single-region monitoring guidance",[16,282,284],{"id":283},"step-4-correlate-ingress-failures-with-probe-states","Step 4: Correlate ingress failures with probe states",[12,286,287],{},"During incident triage, compare:",[99,289,290,293,296,299],{},[102,291,292],{},"Ingress synthetic status",[102,294,295],{},"Pod readiness percentages",[102,297,298],{},"Liveness restart counts",[102,300,301],{},"Ingress controller error rate",[12,303,304],{},"If ingress checks fail and probes pass, look at DNS, TLS, ingress rules, and upstream gateway behavior first.",[16,306,308],{"id":307},"probe-design-guidelines-that-improve-signal","Probe design guidelines that improve signal",[310,311,313],"h3",{"id":312},"readiness-probes","Readiness probes",[99,315,316,319,322],{},[102,317,318],{},"Validate app dependency readiness where safe",[102,320,321],{},"Use timeout that matches real startup profile",[102,323,324],{},"Avoid shallow checks that always return success",[310,326,328],{"id":327},"liveness-probes","Liveness probes",[99,330,331,334,337],{},[102,332,333],{},"Keep liveness checks minimal and stable",[102,335,336],{},"Avoid expensive checks that create restarts under load",[102,338,339],{},"Use restart thresholds that prevent flapping",[310,341,343],{"id":342},"startup-probes","Startup probes",[12,345,346],{},"For slow-boot services, use startup probes so liveness does not restart healthy initialization.",[16,348,350],{"id":349},"alert-policy-example-for-kubernetes-ingress-incidents","Alert policy example for Kubernetes ingress incidents",[21,352,353,366],{},[24,354,355],{},[27,356,357,360,363],{},[30,358,359],{},"Condition",[30,361,362],{},"Severity",[30,364,365],{},"Action",[43,367,368,379,390,400],{},[27,369,370,373,376],{},[48,371,372],{},"Ingress check fails in 3 regions for 2 intervals",[48,374,375],{},"P1",[48,377,378],{},"Page on-call and open incident",[27,380,381,384,387],{},[48,382,383],{},"Ingress fails in 1 to 2 regions for 3 intervals",[48,385,386],{},"P2",[48,388,389],{},"Notify platform channel and create ticket",[27,391,392,395,397],{},[48,393,394],{},"Readiness drops below threshold without ingress impact",[48,396,386],{},[48,398,399],{},"Platform investigation",[27,401,402,405,408],{},[48,403,404],{},"Liveness restart spike with stable ingress",[48,406,407],{},"P3",[48,409,410],{},"Service owner review",[12,412,413,414,196],{},"Pair this with ",[192,415,417],{"href":416},"\u002Fblog\u002Freduce-false-positive-alerts","reduce false positive alerts",[16,419,421],{"id":420},"internal-and-external-checks-both-matter","Internal and external checks both matter",[12,423,424],{},"Kubernetes probes answer \"should this pod run and receive traffic?\"",[12,426,427],{},"Ingress monitoring answers \"can users reach and use the service right now?\"",[12,429,430],{},"You need both to reduce MTTR.",[16,432,434],{"id":433},"recommended-internal-linking-path","Recommended internal linking path",[99,436,437,442,448,454,460],{},[102,438,439],{},[192,440,441],{"href":194},"Best Kubernetes Uptime Monitoring Tools",[102,443,444],{},[192,445,447],{"href":446},"\u002Fblog\u002Fmonitoring-microservices-health-checks","Monitoring Microservices Health Checks",[102,449,450],{},[192,451,453],{"href":452},"\u002Fblog\u002Fsynthetic-monitoring-guide","Synthetic Monitoring Guide",[102,455,456],{},[192,457,459],{"href":458},"\u002Fblog\u002Foauth-sso-login-flow-monitoring","How to Monitor Login Flows with OAuth and SSO",[102,461,462],{},[192,463,465],{"href":464},"\u002Fblog\u002Fmonitor-private-api-behind-vpn-zero-trust","How to Monitor Private APIs Behind VPN and Zero Trust",[16,467,469],{"id":468},"final-checklist","Final checklist",[99,471,472,475,478,481,484],{},[102,473,474],{},"Readiness and liveness probes are configured per workload",[102,476,477],{},"External ingress checks cover critical routes",[102,479,480],{},"Multi-region quorum rules are active",[102,482,483],{},"Transaction checks validate login and checkout",[102,485,486],{},"DNS and SSL checks protect domain and cert path",[12,488,489],{},"If you run this model, you catch real user-impacting outages faster than probe-only monitoring.",{"title":491,"searchDepth":492,"depth":492,"links":493},"",2,[494,495,496,497,498,499,500,501,502,508,509,510,511],{"id":18,"depth":492,"text":19},{"id":93,"depth":492,"text":94},{"id":122,"depth":492,"text":123},{"id":199,"depth":492,"text":200},{"id":203,"depth":492,"text":204},{"id":228,"depth":492,"text":229},{"id":255,"depth":492,"text":256},{"id":283,"depth":492,"text":284},{"id":307,"depth":492,"text":308,"children":503},[504,506,507],{"id":312,"depth":505,"text":313},3,{"id":327,"depth":505,"text":328},{"id":342,"depth":505,"text":343},{"id":349,"depth":492,"text":350},{"id":420,"depth":492,"text":421},{"id":433,"depth":492,"text":434},{"id":468,"depth":492,"text":469},"guides","2026-07-11","Readiness and liveness probes are not enough for uptime. This guide explains the difference between Kubernetes probe signals and ingress monitoring, then shows a layered setup that detects user-facing outages faster.","md",[517,520,523],{"q":518,"a":519},"Do Kubernetes liveness and readiness probes replace ingress monitoring?","No. Probes run inside the cluster and cannot validate internet-path failures, DNS issues, TLS problems, or regional routing outages.",{"q":521,"a":522},"What should I monitor first in Kubernetes for uptime?","Start with external checks on ingress endpoints, then add service-level readiness signals and critical transaction checks.",{"q":524,"a":525},"Why can pods be healthy while users still see downtime?","Because probe success means container-level health, not end-user path health. Ingress, auth, CDN, and dependencies can fail while pods remain ready.",null,{},true,"\u002Fblog\u002Fkubernetes-ingress-monitoring-vs-readiness-liveness-probes",11,{"title":5,"description":514},"blog\u002Fkubernetes-ingress-monitoring-vs-readiness-liveness-probes","AY61M5Lf8UcUQbInw6NaStCOiagGKPkqEToc7-12qkQ",1783676783459]