What Is a 504 Error (Gateway Timeout)?

The 504 first appeared in RFC 2068, the HTTP/1.1 specification of January 1997. RFC 1945 for HTTP/1.0, from May 1996, already had the 502 but not the 504. Today it is defined in RFC 9110, from June 2022, section 15.6.5: the gateway "did not receive a timely response" from the server it needed.

The chain of gateways is explained in the entry on the 502 error. The wording depends on the software (nginx titles its page "504 Gateway Time-out"), but the code is the same.

Every layer that forwards a request decides how long it waits for the next one. If the application takes longer, that layer gives up and answers with a 504. Cloudflare lists a large data query, a long-running process or a server short of resources as causes.

Default values according to each vendor (checked on 13.11.2026):

• nginx: 60 seconds for proxy_read_timeout and fastcgi_read_timeout, counted between two reads.
• Apache httpd: ProxyTimeout takes the value of TimeOut, 60 seconds.
• AWS Application Load Balancer: a 60-second idle timeout and 10 seconds to open the connection.
• Amazon CloudFront: 30 seconds waiting for the origin's response; for GET and HEAD requests it tries again up to three times.
• Cloudflare: 125 seconds; on the Enterprise plan, up to 6,000.
• PHP: 30 seconds for max_execution_time, which by default measures CPU time outside Windows, so time spent waiting on the database does not count.

The shortest limit wins. With nginx at 60 seconds and CloudFront at 30, CloudFront cuts off first. For a POST request, the visitor sees its 504 after 30 seconds; for GET and HEAD, CloudFront retries up to three times and the 504 arrives after about 90. Raising the limit on one layer does nothing if a layer in front of it cuts off sooner.

Cloudflare answers differently: when its 125 seconds run out, it returns a 524, its own code, which RFC 9110 does not define.

One layer can produce a 504 for different reasons. For its load balancer, AWS lists these: it cannot open the connection within 10 seconds, the target does not respond before the idle timeout, a Lambda function does not answer, or the target announces more bytes than it sends.

CloudFront also returns a 504 when a firewall blocks its traffic to the origin or the origin cannot be reached from the internet. No application is slow in that case: the request never arrives.

With Cloudflare, a 504 carrying its logo came from the origin server; a blank page without the logo was generated by Cloudflare.

Worked example: an online shop with Cloudflare in front and nginx with PHP-FPM behind it exports the year's orders, and the query runs for 90 seconds without sending anything. At 60 seconds, nginx returns a 504, which shows up with the Cloudflare logo because it came from the origin.

The administrator raises fastcgi_read_timeout to 180 seconds and the export works. Once the file grows and the query passes 125 seconds, the error comes back as a 524, because Cloudflare's limit is now the one that fires. For such processes, Cloudflare suggests a subdomain that is not proxied.

The duration gives the layer away. curl with the -w option and the variables %{http_code} and %{time_total} prints the code and the seconds. With default values, a 504 after 30 seconds on a POST request, or after about 90 on GET and HEAD because of the three attempts, points to CloudFront, one after 60 to nginx or an AWS load balancer, and a 524 at around 125 to Cloudflare. AWS also suggests measuring the time to first byte, TTFB, on each server.

The log confirms it: when the timeout expires, nginx writes "upstream timed out", according to its source code.

In Search Console, the Crawl Stats report separates "Server error (5XX)", where the 504 falls, from "Page timeout", where the page request timed out.

A long limit lets slow processes finish; a short one shows the error sooner. AWS recommends setting the application's idle timeout higher than the load balancer's: if the application closes the connection first, the load balancer can return a 502.

For SEO, the 504 follows the general 5xx rule: Google's documentation on status codes (4 February 2026) describes the 500, 502 and 503 separately, but not the 504. Its crawlers slow down, ignore the content and keep indexed URLs, "but eventually dropped", with no deadline. What happens when a server error lasts for days is covered in the entry on the 503 error.

A server that does not answer Googlebot at all is a different case. Google treats "network timeouts, connection reset, and DNS errors similarly to 5xx server errors", but without a response there is no status code. According to its page on network errors, crawling slows down immediately, and indexed URLs that cannot be reached are removed from the index "within days".

Source: RFC 9110 (June 2022); Cloudflare, "Error 524" (accessed 13.11.2026).

The 500 is the server's generic failure, and the 503 signals overload or maintenance.

RFC 9110 asks for a "timely" response but sets no number of seconds. With default values, a response that takes 45 seconds triggers a 504 behind CloudFront and arrives normally behind Cloudflare.

Cloudflare defines the 502 and 504 more broadly than the RFC, as being "unable to establish contact" with the origin server.

• Measure with curl how many seconds the 504 takes and compare them with each layer's limit.
• Find the line from that minute in the proxy log and the slow request in the application log.
• Move long tasks out of the web request, into a queue or a cron job, and check their status by polling.
• If a long operation has to stay on the same connection, send at least one byte before the idle timeout runs out, as AWS recommends.
• Only then adjust the limits, from the application outwards, so that no outer layer cuts off first.
• After the fix, check host status in Search Console.
• If you are only visiting the page: reload later; if it works for other people, check your VPN, proxy or DNS, as MDN suggests.

• Log the response time of every request at the origin, as Cloudflare recommends.
• Keep one document with the actual limit of every layer, from the CDN to PHP.

• Raising the nginx limit while a CloudFront distribution in front cuts off at 30 seconds.
• Looking for a 504 when Cloudflare shows a 524.
• Assuming PHP's max_execution_time stops a script after 30 seconds of wall-clock time.
• Assuming Google allows a fixed number of days before dropping URLs that return a 504.

This entry was written in November 2026 with AI assistance, based on the RFCs, Google and Search Console documentation, and documentation from MDN, nginx, Apache, AWS, Cloudflare and PHP. The time limits were checked on 13.11.2026. It contains no client data.