A 504 Gateway Timeout occurs when an upstream server fails to respond within the allowed time window, causing the proxy or gateway to abandon the request. In 2026, this remains one of the most common server-side errors, typically stemming from backend overload, network congestion, or misconfigured timeouts. The key takeaway: it’s almost never a client-side problem.
According to Cloudflare’s 2025 Internet Quality Report, timeout errors account for 18% of all HTTP 5xx failures in production environments. That’s nearly one in five server errors your users might see. When a 504 hits your site, you’re losing conversions, frustrating visitors, and potentially damaging search rankings if the errors persist.
The financial impact isn’t trivial either. A three-second delay can increase bounce rates by 32%, per Google research. A full timeout that takes 30 or 60 seconds? Users are already gone.
The HTTP/1.1 504 Gateway Timeout status code means a gateway or proxy server didn’t receive a timely response from an upstream server it needed to complete your request. Think of it like calling a restaurant: you reach the host, but when they go back to ask the kitchen about your reservation, nobody answers within a reasonable time. The host hangs up.
In technical terms, the server returning the 504 is acting as a gateway—Nginx, Apache, a CDN edge node, or a cloud load balancer. It sent a request to a backend application server, database, or API endpoint and waited. And waited. When the configured timeout expired, it gave up and sent you the 504.
This is distinct from a 502 Bad Gateway, where the upstream server responds but sends back garbage. With a 504, there’s simply no response at all within the deadline.
The root causes fall into a few predictable buckets.
Backend application hangs are the most common. Your PHP-FPM workers are all busy, your Node.js event loop is blocked by a synchronous database query that’s scanning millions of rows, or your Python app is waiting on an external API that’s down. I’ve seen WordPress sites trigger 504s when a plugin makes an HTTP request to a third-party service that never responds—the whole PHP process just sits there until the web server kills it.
Database saturation is next. A query without proper indexes can run for minutes. Connection pools fill up. Replication lag grows. The app server sends a query and waits for a response that arrives too late, if at all.
Network issues between tiers also cause timeouts. Firewalls drop packets. Routing tables break during a deployment. A misconfigured security group in AWS blocks traffic between your load balancer and EC2 instances. The gateway sends requests into the void.
Insufficient timeout values can create false positives. If your Nginx proxy_read_timeout is 30 seconds but your backend task legitimately takes 45 seconds, you’ll see 504s even though the backend is working fine. It’s just slow.
DDoS attacks and traffic spikes overwhelm backends, exhausting CPU, memory, or file descriptors. Legitimate requests wait in queues that never drain.
Start with the gateway layer. Check your reverse proxy logs—Nginx, Apache, HAProxy, or your CDN dashboard. Look for upstream timeout entries. In Nginx, you’ll see lines like:
upstream timed out (110: Connection timed out) while reading response header from upstreamThat tells you Nginx gave up waiting for the backend. Now move upstream.
Check backend application logs. Is the app even receiving the requests? Are they logging slow queries or external API calls? Use application performance monitoring if you have it—tools like New Relic or Datadog will show you exactly which transaction is hanging.
Examine database performance. Run SHOW PROCESSLIST; in MySQL or SELECT * FROM pg_stat_activity; in PostgreSQL. Look for queries in “executing” state for dozens of seconds. Check slow query logs.
Test network connectivity between layers. SSH into your gateway server and try curling the backend directly:
curl -v http://backend-server:8080/healthDoes it respond quickly? Does it respond at all? Use traceroute or mtr to spot routing problems.
Monitor resource usage. Run top, htop, or check your cloud metrics. Is the backend server at 100% CPU? Out of memory? Disk I/O saturated?
The fix depends on the cause, but here are the most effective interventions.
Increase timeout values as a temporary measure. In Nginx, adjust these directives:
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;For Apache with mod_proxy, set:
ProxyTimeout 60Don’t just crank timeouts to 300 seconds and call it done. That masks the real problem.
Optimize slow backend processes. Add database indexes, cache expensive queries, offload long-running tasks to background workers. In WordPress, use object caching with Redis or Memcached to reduce database load. A well-configured Redis instance can drop query counts by 70-80%.
Scale horizontally. Add more backend servers and distribute load. Use connection pooling to reuse database connections efficiently. In Node.js, use clustering or PM2. For PHP, increase the number of PHP-FPM workers.
Implement timeouts on outbound requests. If your app calls external APIs, set aggressive timeouts—3 to 5 seconds—and handle failures gracefully. Don’t let a slow third-party service bring down your entire stack.
// Node.js example
const response = await fetch(apiUrl, {
signal: AbortSignal.timeout(5000)
});Use health checks and circuit breakers. Configure your load balancer to stop sending traffic to unhealthy backends. Implement retry logic with exponential backoff.
Monitor and alert proactively. Set up alerts for response times exceeding thresholds before they hit the timeout limit. Fixing a 3-second response is easier than debugging a 60-second hang.
There’s no universal answer, but here’s what works for most web applications.
For reverse proxy to application server: 30-60 seconds is standard. API endpoints should respond faster—10 to 30 seconds. Admin panels or report generation can justify 60-120 seconds.
For application to database: 5-10 seconds for OLTP queries. Anything slower needs optimization. Analytical queries in a separate read replica can run longer.
For application to external APIs: 3-5 seconds maximum. Assume third-party services are unreliable.
Keep timeouts consistent across the stack. If your load balancer times out at 30 seconds but Nginx waits 60, you’ll see inconsistent behavior.
Server-side. The 5xx status code family indicates the server failed to fulfill a valid request. Nothing the client did caused this, and refreshing the page rarely helps unless the backend recovers quickly.
A 502 Bad Gateway means the upstream server responded, but the response was invalid or corrupt. A 504 means the upstream server didn’t respond at all within the timeout period. Different symptoms, different fixes.
Yes, if your origin server takes longer than 100 seconds to respond, CloudFlare will return a 524 timeout (which looks similar). More commonly, CloudFlare returns a 504 when your origin is completely unreachable or refusing connections.
Rarely. It might reduce the frequency, but if your backend takes 90 seconds to respond, you have a performance problem that longer timeouts won’t fix. Users won’t wait that long anyway.
Use auto-scaling to add capacity automatically, implement rate limiting to protect backends, enable caching for static and semi-static content, and use a CDN to absorb traffic at the edge. Queue non-critical tasks instead of processing them inline.