Server
HTTP 504
Also called Gateway Timeout.
HTTP 504 is a gateway or proxy reporting that the server behind it did not answer within its timeout. The connection was made, but the wait ran out.
How it is measured
Compare the proxy timeout with the upstream's actual response time. In Nginx the relevant setting is `proxy_read_timeout`, 60 seconds by default, and the log line reads 'upstream timed out (110: Connection timed out) while reading response header'.
Plot the response time of the slowest requests alongside 504 count. The 504s cluster on whatever endpoint runs past the limit, such as an export, a report or a call to a slow third party.
Worked example
An admin exports 40,000 customers to CSV on a WordPress site. The query and render take 74 seconds. Nginx waits 60 seconds, returns 504 at the 60th, and the PHP process carries on to finish work nobody receives.
The team moved the export to a background job that emails a link when ready. The request returns in 200 ms, and the 504 count on /wp-admin/ dropped to zero.
How it differs
HTTP 504 is an upstream that answered too slowly. HTTP 502 is an upstream that answered badly or refused. A 504 excludes any malformed reply, because there was no reply in time. A 502 excludes a pure slow response. Raising a timeout only helps the 504 case, and only if the user will wait.
Common errors
Raising proxy_read_timeout and calling it fixed. Checking the proxy but not the CDN's own shorter timeout. Letting the app keep working after the client has gone. Mixing up the 100-second Cloudflare limit with the origin's. Not finding which endpoint produces the timeouts.
In practice
List the five slowest endpoints in your logs, compare their p99 with the proxy timeout, and move any that approach it to a queue. Use one timeout chain, with the app shorter than the proxy and the proxy shorter than the CDN.