---
title: "504 Gateway Timeout"
canonical: "https://lemwatch.com/http-status-codes/504"
category: "server-error"
last_verified: "2026-08-11"
source: "https://lemwatch.com"
---

# HTTP 504 Gateway Timeout

**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 it means

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

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

## Monitoring tip

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.

**Related:** [500](https://lemwatch.com/http-status-codes/500.md), [502](https://lemwatch.com/http-status-codes/502.md), [503](https://lemwatch.com/http-status-codes/503.md), [408](https://lemwatch.com/http-status-codes/408.md), [521](https://lemwatch.com/http-status-codes/521.md), [522](https://lemwatch.com/http-status-codes/522.md)

_Canonical HTML page: https://lemwatch.com/http-status-codes/504_