Server Error

HTTP 504 Gateway Timeout

A proxy or gateway server didn't receive a response from the upstream server in time — the "slow backend" failure mode that's different from 502 (broken backend).

Check a URL for HTTP 504

Paste any URL to see whether it currently returns 504. Runs a live HTTP probe and follows redirects.

TL;DR

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 underlying slowness still hurts users and Core Web Vitals.

What does HTTP 504 mean?

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.

Common Causes

•Slow database query — missing index, full table scan, lock contention
•Synchronous call to a slow third-party API (Stripe, SendGrid, OpenAI) without a tight timeout
•Long-running PDF generation, image processing, or report export on the request path
•Proxy timeout configured too aggressively (Nginx default proxy_read_timeout is 60s)
•Origin server overloaded — has the connection, can't process it in time
•Network latency between the proxy and origin (cross-region deploy, VPN, slow link)
•Deadlock or thread starvation in the application

How to Fix It

1.Identify the slow request: most app frameworks log slow requests, or use APM (New Relic, Datadog, Sentry Performance) to find the >5s endpoints
2.Profile the slow endpoint: 90% of the time it's a database query — EXPLAIN ANALYZE will show the missing index
3.Add indexes for any query taking >100ms; switch sync external API calls to async/queued work
4.Move heavy work (PDF generation, large exports, AI calls) off the request path with a job queue (Sidekiq, Bull, SQS, Cloud Tasks)
5.Add a tight timeout to every outbound HTTP call — never let a slow external API hang your whole request
6.Increase proxy_read_timeout only after the backend work is genuinely the right duration (e.g. a streaming endpoint)
7.For Cloudflare: free plans cap at 100s (you'll see 524, not 504); Enterprise supports up to 6000s if needed
8.Add caching (Redis, Varnish, CDN edge cache) for expensive responses that don't change often

SEO Impact

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.

Monitor HTTP 504 with LemWatch

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.

History & Context

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.

Real-World Examples

Cloudflare 524 timeout

Cloudflare returns 524 (its proprietary code) instead of 504 when the origin response exceeds 100s on free plans. Many sites mistake 524s for 504s — the root cause is usually identical: a slow backend.

AWS ALB idle timeout

AWS Application Load Balancer's default idle timeout is 60s. A request that takes 65s to respond will fail with 504 even if the backend eventually finishes. Common cause of 504s on Lambda/serverless backends that exceed the ALB timeout.

WordPress page builders

Heavy page builders (Elementor, WPBakery) plus image-heavy pages plus shared hosting frequently trigger 504s — the backend takes too long to render. The fix is almost always full-page caching with WP Rocket or LiteSpeed Cache.

Tuning 504 timeouts the right way

nginx

# Nginx upstream timeouts — defaults are 60s each
location / {
    proxy_pass http://app_upstream;

    # How long Nginx waits for the upstream to send each chunk of the response.
    # Bump this only if the backend genuinely streams long responses.
    proxy_read_timeout 60s;

    # How long Nginx waits to establish the TCP connection.
    # 5s is plenty in a normal LAN; if you're hitting this, the upstream is down.
    proxy_connect_timeout 5s;

    # How long Nginx waits to send the request to the upstream.
    proxy_send_timeout 60s;
}

# Better than bumping timeouts: tighten outbound HTTP calls in the app.
# Node.js example — never let a slow third-party API hang the whole request:
#   const res = await fetch(slowApi, { signal: AbortSignal.timeout(3000) });

Frequently Asked Questions about HTTP 504

What does HTTP 504 mean?

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.

How do I fix HTTP 504 errors?

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.

What is the difference between 502 and 504?

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.

Why does my site return 504 errors intermittently?

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.

What is the difference between 504 and Cloudflare's 524?

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.

How do I increase the timeout to fix 504 errors?

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.

Does 504 affect SEO?

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.

How do I prevent 504 errors during traffic spikes?

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.