TinyPingTinyPing

504 Gateway Timeout: Check, Causes and Fixes

Check whether a URL returns 504 Gateway Timeout right now and how long the request takes, so you can match it against your proxy's timeout. Enter a URL such as https://example.com.

Common causes of 504 Gateway Timeout

A slow request hits the proxy's read timeout

nginx waits 60 seconds for an upstream response by default (proxy_read_timeout, or fastcgi_read_timeout for PHP-FPM). A report export, a big import or an unindexed database query that runs longer produces 504. The nginx log says "upstream timed out (110: Connection timed out) while reading response header from upstream". Find the slow request first; raising the timeout only hides it.

Work that belongs in a background job

Sending hundreds of emails, resizing images or calling a slow third-party API inside the web request will eventually exceed some timeout in the chain. Move the work to a queue, answer the request right away with 202 Accepted or a job id, and let the client poll or receive a webhook.

The database or an external API is stuck

If every page times out at once, the app is probably waiting on something shared: a locked table, an exhausted database connection pool, a Redis that stopped answering, or a payment or search API that hangs. Check those dependencies before the web servers.

Packets to the upstream are silently dropped

A firewall rule, security group or wrong private IP that drops traffic (rather than refusing it) leaves the proxy waiting until proxy_connect_timeout runs out. The log then says "while connecting to upstream". Test the connection from the proxy host with curl or nc to the upstream address.

Managed gateway limits you cannot raise far

AWS API Gateway gives integrations 29 seconds by default, CloudFront waits 30 seconds for the origin by default, and an AWS ALB times out after its idle timeout (60 seconds by default). Behind Cloudflare, a slow origin gets error 524 after 100 seconds on most plans rather than a 504. Design long operations around these limits.

Serverless cold starts and function timeouts

A Lambda, Cloud Run or Vercel function that has to start cold, then connects to a database, can push a request over the gateway's limit. If the function's own timeout is longer than the gateway's, the gateway gives up first and returns 504 while the function keeps running.

How to troubleshoot a 504

  1. Enter the URL and click Check status, and note how long the request took.
  2. Compare that time with each timeout in the chain: CDN, load balancer, proxy, app server.
  3. Find the request in the app and database logs to see where the time went.
  4. Speed up or move the slow work to a background job, then check again.

What does 504 Gateway Timeout mean?

504 Gateway Timeout means a proxy or gateway did not get a response from the upstream server before its timeout ran out. The proxy itself is working. It waited for the application, gave up, and told you so.

The response time is the most useful clue. A 504 that arrives after almost exactly 30, 60 or 100 seconds points straight at the component with that timeout. A 504 that arrives quickly usually comes from a proxy that could not even open a connection.

A 504 does not mean the work failed. The application may still be processing the request after the proxy has given up, which is how users end up submitting a form twice and getting two orders. Long actions should be idempotent or run as background jobs.

Raising timeouts is sometimes right, for example an admin export that legitimately takes two minutes. For normal pages, a request that takes more than a few seconds is the real problem, and the 504 is just where it became visible.

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 5s;
    proxy_read_timeout 60s;   # default; slower responses become 504
}

When to check for a 504

Slow admin pages in WooCommerce or Magento

Order lists and reports that grow with the store start timing out one day. Check the URL and note the time to see which limit it is hitting.

APIs behind AWS API Gateway

An endpoint that works in development returns 504 in production once real data makes it slower than the integration timeout.

After a database migration

A dropped index or a new table lock turns a fast page into a timeout. Check the main pages after the migration runs.

Behind Cloudflare or a CDN

Compare the time a check takes with the CDN's origin timeout to tell a CDN limit from your own nginx limit.

Check something else

Frequently asked questions

What is the difference between 504 and 502?

A 504 means the upstream did not answer before the proxy's timeout. A 502 means it answered with something invalid or refused the connection. Slow apps produce 504, crashed apps usually produce 502.

Should I just increase the timeout?

Only for requests that really need more time, such as exports. For normal pages, longer timeouts mean visitors wait longer and workers stay busy, which can turn a few slow requests into an outage.

Why does the 504 come back after exactly 60 seconds?

60 seconds is the default for nginx's proxy_read_timeout and for the AWS ALB idle timeout. A 504 at that mark tells you which setting ran out.

Is a 504 my internet connection?

No. The 504 was produced by a server between you and the application. A slow connection on your side shows up as a browser timeout, not as a 504 page.

Did my request still go through?

Possibly. The proxy stopped waiting but the application may have finished the work. Check whether the order, upload or change exists before trying again.

What is Cloudflare error 524?

Cloudflare's version of a timeout: it connected to your origin, but the origin did not send a response within 100 seconds. Treat it like a 504 from your own proxy.

Slow today, down tomorrow

Timeouts usually start with one page getting slower as data grows. TinyPing checks every 5 minutes, records response time and alerts you when:

  • the URL returns 504 or another error code
  • the request times out completely
  • the site recovers after an incident
Start monitoring free for 7 days

US$6.99 a month or US$47 a year per 50 monitors, team members free. 7-day free trial, no card needed.

Want alerts in team chat? Follow the guide for Slack or Google Chat.