504 gateway timeout, and "the website is down": how to tell what actually broke

By Angus Lewington, Alien Web Design · Last reviewed: 15 August 2026 · Reviewed every 6 months

"The website is down" describes a symptom, and at least five unrelated faults produce it. DNS, the server, the TLS certificate, a proxy in front of the server, and the site's own code all fail in ways that look identical from a browser. The good news is that these are strictly layered, so five minutes of checking in the right order will tell you which one it is, and that single fact turns a guessing session into a specific job for a specific person.

What a 504 actually means

Precision matters here, because the three codes people treat as interchangeable point at genuinely different faults.

A 504 Gateway Timeout means a server acting as a gateway or proxy did not get a response in time from the server behind it. MDN's definition is worth reading closely: a 504 is sent specifically when "the proxy or gateway did not receive any HTTP response from the origin". Not a slow response, not an error response. Nothing at all.

The distinction is diagnostic, not academic. A 502 says your application ran and produced something broken. A 504 says it never answered. Those lead to opposite investigations, and the fastest way to waste an afternoon is to debug application code when the code was never reached.

The triage ladder

Work down these in order. Each rung rules out everything below it, so stopping at the first failure saves you the rest. The terminal commands are the fastest route; equivalent web based tools are noted for each if you do not have one.

1. Is it only you?

   Load the site on your phone with wifi turned off, so you are on mobile data and a different resolver. Also try an outside checker such as a down-detector service.

   Works elsewhere: the site is fine and your network is not. Check for a VPN, a stale hosts file entry, a corporate proxy, or a captive portal. Flush your DNS cache. Stop here.
   Fails everywhere: keep going.

2. Does the name resolve?

   dig +short example.com.au (Windows: nslookup example.com.au 1.1.1.1)

   No answer, or the wrong address: this is a DNS fault, and nothing below matters until it is fixed. The usual causes are an expired domain, nameservers pointing at a provider you have left, or a record edited in a zone that is not authoritative. Confirm with dig NS example.com.au, then see changing DNS records and nameservers.
   If you changed DNS recently and it half works, that is cache expiry rather than a fault. How long it takes is predictable.

3. Does the server answer at all?

   curl -I -m 15 http://example.com.au

   Connection refused: nothing is listening. The web server process is stopped, or a firewall is blocking the port.
   Times out with no response: the server or its firewall is silently dropping traffic. This is also what produces a genuine 504 at any proxy in front of it.
   Any HTTP status comes back, even an error: the server is alive and reachable. Move on.

4. Is the certificate valid?

   openssl s_client -connect example.com.au:443 -servername example.com.au and read the notAfter date. Any online SSL checker does the same job.

   Expired or mismatched: visitors get a full page browser warning, not a 504. It is worth checking here because it is the single most common "the website is down" report that turns out not to be an outage at all. Auto renewal failing quietly is the usual cause.
   Valid: the fault is above TLS, in the application.

5. What is the actual status code, and who sent it?

   curl -sI https://example.com.au

   Read the status line, then the server header. This tells you whether you are looking at your own server's error or at something a proxy in front of it generated. The next section is entirely about that difference.

The 504 you are looking at may not be a 504

If the site is behind Cloudflare, and a great many Australian sites are, the error page in front of you was very likely written by Cloudflare rather than by your server. Cloudflare uses its own numbered codes in the 5xx range, and they are far more specific than a generic 504:

Why this matters: these codes prove the problem is between Cloudflare and your origin server, which means your DNS is working and the request is arriving. It also means a support ticket to Cloudflare is usually the wrong call, because the fault is at the origin. Cloudflare's own guidance is that the cause is not always in the origin server's logs, and to also check any load balancer, cache, proxy or firewall sitting between them.

A 521 in particular is worth knowing on sight: it very often means someone tightened the origin firewall and did not allow Cloudflare's IP ranges, so the site went dark immediately after a security change that looked unrelated.

What causes a genuine 504

Once you have established it is a real timeout at your origin, the causes cluster into a short list:

• A slow database query or a long running script. The request is still working when the proxy gives up. On WordPress this is usually a plugin doing something expensive on every page load, an import or cron job running in the foreground, or a search query across a large table with no index.
• PHP or application worker exhaustion. Every worker is busy, so new requests queue and never get served. The site is not crashed, it is saturated, which is why it often recovers on its own and then fails again under load.
• The upstream service is down. If your app calls an API, a payment gateway or a separate database server, and that call hangs with no timeout, your page hangs with it. Always set timeouts on outbound calls.
• Genuine resource limits. Out of memory, disk full, or connection pool exhausted. Disk full is the sneaky one, because it breaks logging at the same moment, so the logs that would explain it are the logs that stopped being written.
• A firewall or rate limiter dropping traffic silently. Dropping a packet rather than rejecting it produces a timeout rather than a refusal, which is exactly what a 504 is made of.

If you are a visitor and not the site owner

Almost nothing on your side will fix a 504, and most advice telling you otherwise is padding. Realistically:

• Wait a few minutes and try again. Overload driven 504s often clear on their own.
• Try the site on another network, such as mobile data. If it works there, the problem is your connection, your VPN or your DNS, and that you can fix.
• If you need the content rather than the site, a search engine's cached copy may still have it.
• If it is a business you need to reach, phone them. They frequently do not know yet.

If it is your site

Work in this order, because it goes from most to least reversible:

1. Capture evidence before you change anything

   Note the exact error, the time, and the URL. Save the output of the curl commands above. If you start restarting services first, you destroy the state that would have explained the fault, and it will happen again.

2. Check the obvious resource limits

   Disk space, memory, and whether the database is accepting connections. Disk full explains a startling proportion of sudden outages and takes seconds to rule out.

3. Read the logs from the right layer

   The web server error log tells you what the proxy saw. The application log tells you what the code did. For a 504, the web server log is the one that matters, because the application may have no record of a request it never finished.

4. Ask what changed

   A deploy, a plugin update, a firewall rule, an expiring certificate, a DNS edit, or a traffic spike. Outages that appear without a change are rarer than outages where somebody forgot about a change.

5. Only then restart things

   Restarting clears the symptom and destroys the evidence. Sometimes that trade is worth it, when the site is commercial and every minute matters. Make it a decision rather than a reflex.

The short version

A 504 means a proxy got nothing back from your server, which is a different fault from a 502 (it answered with something broken) and a 503 (it answered and said it was busy). Check in layers: only you, then DNS, then does the server answer, then the certificate, then the application. Stop at the first failure, because everything below it is unmeasurable until that one is fixed. If the site sits behind Cloudflare, read the specific error number, because a 521 or 524 tells you far more than a generic 504 does and points you at the origin rather than the CDN. And capture the evidence before you restart anything, or you will be doing this again next week with no more information than you have now.

General guidance only. If your site is commercial and currently down, diagnose in this order but do not let the process delay a call to your host if you cannot reach the server at all.

Where this comes from

The primary sources behind the above, so you can check any of it yourself rather than take our word for it:

• MDN: 504 Gateway Timeout and 502 Bad Gateway, for the precise distinction between receiving an invalid response and receiving none.
• MDN: 503 Service Unavailable, including the Retry-After header and why 503 responses should not be cached.
• Cloudflare: 5xx errors, the source for errors 520, 521 and 524 and for the advice to check intermediate load balancers and firewalls.