A 504 means the proxy reached your app server but the app took too long to respond. The fix is in the backend, not the proxy: find the slow query, the blocked external API call, or the unindexed loop. Bumping the proxy timeout treats the symptom — the…
HTTP 504 Gateway Timeout fires when a proxy server (Nginx, Cloudflare, an AWS ALB) successfully connects to the upstream application server, sends the request, and then waits — but the upstream takes too long to send a response back, exceeding the proxy's configured timeout. The TCP connection is fine; the application is just being slow. This is fundamentally different from 502 Bad Gateway (where the connection itself fails) and from 503 Service Unavailable (where the server deliberately says "not now"). 504 is almost always a performance problem in the backend: a slow database query, a long-running API call, an unindexed loop, or a downstream dependency that's itself slow.
Persistent 504s damage SEO in two ways simultaneously. First, Google deindexes pages that consistently fail to respond — same as any 5xx error. Second, even when the page eventually responds, the slow response time hurts Core Web Vitals (specifically LCP — Largest Contentful Paint), which is a confirmed ranking factor. A 504 that intermittently resolves into a 6-second 200 is still a ranking problem. Fix the backend slowness, don't just bump the proxy timeout.
LemWatch tracks response times alongside status codes — so we can alert you when response times approach your gateway timeout threshold (e.g. >50s on a 60s timeout) before they cross over and start producing 504s. We also distinguish between 504 (proxy timeout) and 524 (Cloudflare timeout) so you know which layer is failing.
HTTP 504 was defined in RFC 2616 (1999) and gained importance with the rise of reverse-proxy and CDN architectures. Cloudflare's default origin timeout is 100 seconds on free plans, which is why 524 (Cloudflare's own timeout code) is more common than 504 for Cloudflare-fronted sites. Behind AWS ALBs and Nginx, 504 is the standard symptom of a slow database query or a sync HTTP call to a slow third-party API.
HTTP 504 Gateway Timeout means a proxy server (Nginx, Cloudflare, AWS ALB) connected to the upstream application server successfully but didn't receive a response in time. The TCP connection works; the application is just being too slow.
The fix is almost always in the backend, not the proxy. Find the slow endpoint (most app frameworks log slow requests, or use APM tooling), profile it (usually a database query without an index), and either optimise it or move the work off the request path with a job queue. Bumping the proxy timeout treats the symptom.
502 Bad Gateway means the proxy couldn't connect to the upstream, or the upstream returned an invalid response. 504 Gateway Timeout means the connection succeeded but the upstream took too long to respond. 502 = broken backend; 504 = slow backend.
Almost always backend performance variance: slow database queries that occasionally lock, third-party API calls that occasionally hang, or a connection pool that occasionally exhausts. APM tooling (New Relic, Datadog, Sentry) traces the slow requests to find the culprit.
504 is the standard HTTP status code for "the upstream took too long." Cloudflare additionally returns 524 — its proprietary code — when the origin response exceeds 100 seconds on free plans. Same root cause (slow backend), different code depending on which proxy layer timed out.
For Nginx: proxy_read_timeout in your location block. For AWS ALB: the idle_timeout setting. For Cloudflare: only Enterprise plans can extend the 100s origin timeout. But bumping the timeout is treating the symptom — slow responses still hurt users and Core Web Vitals. Fix the underlying backend slowness.
Yes, in two ways. Persistent 504s cause Google to deindex affected pages (same as any 5xx). And even when the page eventually responds, the slow response time hurts Core Web Vitals (especially LCP), which is a ranking factor. Fix the backend speed, not just the timeout.
Cache aggressively at the edge (CDN full-page cache, Cloudflare APO, Varnish), tune database connection pools to handle peak concurrency, move heavy work off the request path with queues, and autoscale the backend horizontally before peak traffic hits.