About the 502/503/504 Debugger
502, 503, and 504 errors all mean "the thing in front couldn't get a good answer from the thing behind" — but each points at a different failure. A 502 means the upstream sent garbage or reset the connection, a 503 means nothing was available to ask, and a 504 means the upstream simply never answered in time. Triaging them as one symptom wastes the first fifteen minutes of every incident.
This playbook walks the path a request actually takes — load balancer, ingress, service, pod — with the specific checks at each hop that distinguish a dead backend from an exhausted connection pool from a timeout mismatch between layers.
Frequently asked questions
What is the practical difference between 502, 503, and 504?
502 Bad Gateway: the proxy reached the upstream but got an invalid response — crashed worker, connection reset, wrong protocol. 503 Service Unavailable: no healthy upstream to try — empty load balancer target group, all pods failing readiness. 504 Gateway Timeout: the upstream accepted the request but exceeded the proxy's timeout — slow database call, deadlock, undersized workers.
Why do I get 504s when my application timeout is set higher?
Timeouts must increase as you move inward; any outer layer with a shorter timeout wins. If the ALB idle timeout is 60s but your app legitimately takes 90s, the client sees 504 regardless of app settings. Map every hop's timeout — CDN, LB, ingress, sidecar, app server — and ensure each outer layer's timeout exceeds the inner one's.
Where do I look first in Kubernetes for 502/503 errors?
kubectl get endpoints <service> — an empty endpoints list explains 503 immediately (readiness probes failing or selector mismatch). For 502s, check whether pods restarted at the error timestamps (kubectl get pods -o wide) — a container that OOMs mid-request produces exactly one 502 per in-flight request.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.