root@hack3rs:/srv/www$ curl -i /504/
HTTP/1.1 504 Gateway Timeout
A gateway or proxy gave up waiting for the upstream to respond.
status-summary.log
HTTP 504 Gateway Timeout
The request got through the edge layer but the upstream service did not respond within the timeout window.
Compare actual upstream response time against the timeout configured at each layer. Increasing timeouts globally is rarely the right fix — find why the backend is slow.
likely-causes.lst
- $Upstream service slow due to load, a long-running query, or lock contention.
- $Network latency or packet loss between the proxy and backend.
- $Gateway timeout is shorter than normal backend response time under peak load.
- $Thread or worker pool exhaustion queuing requests at the backend.
recovery-steps.md
- Pull upstream latency metrics and slow-query traces for the time window.
- Compare timeout values at the CDN, reverse proxy, and application server layers.
- Profile and optimize the slow backend operation — add caching or an index before extending timeouts.
- Scale backend workers and monitor queue depth during the incident.
quick-actions.sh
ops-note.txt
Use these pages for debugging and user guidance. In production, configure your host or reverse proxy to return the matching HTTP status code for the route (especially for 504 and 404/500 responses) rather than serving a 200 with error-themed content.