HTTP 502 vs 503 vs 504

How does it work?

Reverse proxies and load balancers sit between clients and applications. They return gateway errors when upstream connection, response, capacity, or timeout conditions prevent a normal response.

What can go wrong?

Generic retries can amplify overload, while monitoring only for connection failure misses these application-path outages.

How can teams detect the problem?

Record status, response headers, latency, region, endpoint, upstream health, and whether direct origin checks differ from the public gateway.

How can teams fix or reduce the problem?

Tune timeouts carefully, add capacity and health checks, use bounded retries with backoff, and monitor both public and internal dependencies.

What does a technical example look like?

502: proxy got malformed/reset response
503: service intentionally unavailable or overloaded
504: proxy waited beyond upstream timeout

The example uses reserved documentation domains and addresses. Apply the same reasoning to systems you own or are authorized to assess.

Authoritative technical references

• RFC 9110: HTTP Semantics

How does continuous monitoring help?

A point-in-time check explains the observed state now. Continuous monitoring establishes an expected baseline, repeats the relevant check, and records meaningful state changes so an owner can investigate before a small configuration drift becomes a prolonged security or availability problem. See Networking for the surrounding technical context.

Where does Sentryx Monitor fit?

Sentryx Monitor provides read-only outside-in discovery and monitoring for public hosts, DNS, HTTPS, TLS certificates, baseline security headers, email-security records, and selected network services. It supports evidence and operational follow-up, but it does not replace authorized penetration testing, authenticated vulnerability assessment, or owner validation.