Three codes, three starting points
| Code | Meaning | Useful next check |
|---|---|---|
| 502 Bad Gateway | A gateway received an invalid upstream response. | Gateway logs and upstream connection details |
| 503 Service Unavailable | The service is temporarily unable to handle the request. | Maintenance, capacity, readiness and Retry-After |
| 504 Gateway Timeout | A gateway did not receive an upstream response in time. | Upstream latency and timeout boundaries |
The code is a starting clue, not a root-cause diagnosis. A branded error page may identify the proxy that generated it, while the failure itself began elsewhere. Compare the response headers and request ID with logs from the relevant layer. MDN documents 502, 503, and 504 separately.
Worked example: an export fails at about 30 seconds
Suppose ordinary pages load, but a large report export repeatedly returns 504 after roughly 30 seconds. That pattern suggests a timeout boundary worth investigating. It does not prove that the database is slow or that the gateway timeout is misconfigured.
Capture three test runs with their request IDs and elapsed times. Match each to the gateway log and the application log. If the application finishes at 42 seconds after the gateway has already responded, investigate the expensive work and how exports are delivered. A background job with a later download may fit better than keeping a request open. If the application never sees the request, focus earlier in the path.
Increasing the timeout alone can leave requests occupying workers for longer. Measure where time is spent and consider capacity before changing a limit. Test the proposed change under representative conditions, including a failed dependency.
A small incident worksheet
- Define the scope. Is one endpoint affected, one region, one account, or every request? Record when it began and any nearby deployment.
- Record the response. Keep the status, request ID, hostname, timing, and a short description of the operation. Remove secrets from attachments.
- Identify the responder. Find which proxy or application generated the error. Do not assume the visible hostname identifies the failing process.
- Compare logs across layers. Match timestamps and IDs through edge, gateway, application, and dependencies. Check clock differences when events appear out of order.
- Test one hypothesis. For example, compare a small report with a large one using a safe test account.
- Verify recovery. Check the original failing operation and watch error rate and latency, rather than relying on one successful homepage request.
Retry with the operation in mind
A 503 may include Retry-After. Respect the service’s retry guidance and use bounded backoff in automated clients. Repeated immediate retries can add load during an outage. A gateway error after a payment or order submission does not establish whether the upstream operation completed. Check the transaction state or use the service’s documented idempotency mechanism before resubmitting.
Separate HTTP from connection failures
If the browser cannot resolve the hostname or complete its TLS connection, it may never receive an HTTP status. Start with DNS or certificate investigation in that case. Conversely, a gateway can receive your HTTPS request successfully and then encounter a TLS problem connecting to its own upstream. That can surface as a gateway error.
SSL Certificate Checker examines the public hostname through its external checking service. It cannot prove that a private gateway-to-origin connection uses the same certificate or trust settings. HAR Viewer exposes the browser’s recorded perspective; it cannot reveal database queries or private service traffic absent from the capture. Together, these tools help you choose the next investigation, not certify the entire service.
Try the related tools
Continue reading
Sources and review
Examples are illustrative. Reviewed September 28, 2026 against the sources above and the related tool interfaces. Editorial methodology · Report a correction.