Visit Website →
← Back to blog

504 Gateway Timeout: What It Means and How to Fix It

October 25, 2026
504 Gateway Timeout: What It Means and How to Fix It

A 504 Gateway Timeout means one server, acting as a gateway or proxy, asked another server for a response and did not get one in time. Per MDN's reference for the status code, the gateway is waiting on an upstream server. Your browser is usually fine. If you are just visiting, reload once and try another network. If you run the site, find which layer timed out and why the origin was slow.

This guide covers both sides: a short checklist for visitors, then a diagnostic order for owners, including sites that sit behind a CDN.

inSave Hosting
insave.hosting
Keep Your Website Running Smoothly
InSave Hosting offers hosting with 99.9% uptime, LiteSpeed technology, and managed security features for business websites.
Explore hosting

TL;DR

  • A 504 is a timing failure between servers. It is not a verdict that the whole site is down.
  • Visitors can reload, try a private window, switch networks and turn off a VPN. If nothing works, report the URL and time to the site owner.
  • Owners should find which hop produced the 504, then check the origin's health, load, database and logs.
  • Raising a timeout only helps when the work legitimately takes longer. It hides the symptom if the origin is simply too slow.
  • Behind a CDN, first decide whether the error came from the origin or the CDN, and keep the timestamp and failing URL for support.

Table of Contents

What a 504 actually tells you

Modern websites rarely answer from one machine. A request may pass through a CDN, a load balancer, a reverse proxy such as nginx, an application server and a database. Each hop waits for the next one, and each has a time limit.

Website request path through five infrastructure layers

A 504 appears when one hop runs out of patience. MDN explains that the gateway did not get a response in time from the upstream server. That is different from a 502, where the gateway did get a response and it was invalid. If you are chasing the second one, our 502 Bad Gateway guide walks through it.

The code is a symptom, not a diagnosis. The proxy can be perfectly healthy while the application, the database, a firewall rule, the network path or a third-party API is slow. The first useful question is always: which hop sent this response, and what was its timeout?

Is a 504 your fault?

Usually not, if you are only visiting. The fault normally sits upstream of the gateway, which is why the same page often works a few minutes later with no change on your side.

There are exceptions. MDN notes that client-side networking, VPN, proxy, firewall or DNS configuration can matter, particularly when the site works for other people but not for you.

Does a 504 mean the website is down?

No. It means one request path timed out. The site may load on refresh. Another page may work. Cached content may still be served. Or only a specific origin, region, CDN path or long-running operation may be failing. Amazon CloudFront's documentation lists several ways a 504 can occur, including an origin that is unreachable, blocked by a firewall or security group, or just slow to respond.

If the errors keep coming or hit every page, treat it as an outage. Our guide to mapping downtime causes to fixes helps you sort one from the other.

If you are a visitor: the low-risk checklist

Work through these in order. Each takes under a minute.

  1. Wait a few seconds and reload. Many 504s are momentary spikes.
  2. Open the page in a private window or another browser. This rules out a stale cache or a misbehaving extension.
  3. Turn off your VPN or proxy briefly. MDN supports checking VPN, proxy, firewall and DNS settings when the service works for other visitors.
  4. Try a different network. Switch from Wi-Fi to mobile data, or the reverse. If the site loads, the problem is on your first connection.
  5. Check whether others see it. Ask a colleague, or try from another device.
  6. Tell the site owner. Send the exact URL, the time and your time zone. That is what an owner needs to find the entry in their logs.

Do not resubmit checkouts and forms

If the 504 appeared after you pressed Pay, Submit or Place Order, do not click again straight away. The first request may have reached the server and been processed even though your browser showed a timeout. Check your email for a confirmation, or look at your account's order history, before you try again. If you are unsure, contact the business and ask. This is practical advice, not a claim that every timed-out request was processed.

If you own the site: find the slow hop

The diagnostic order below follows the sequence in AWS's guidance for load balancer 504s: measure first, fix capacity and code next, and change timeouts last.

Step 1: Work out which layer answered

Check the response headers and the error page. Does it come from your CDN, your load balancer, your web server or your application? On AWS, for example, if an Application Load Balancer shows no HTTPCode_ELB_504_Count data, the application servers returned the 504, not the load balancer. Without knowing the hop, you will tune the wrong setting.

Step 2: Check that the origin is reachable

Confirm the origin answers on the expected port and hostname. Firewalls, security groups and network rules are a common culprit. CloudFront documents that traffic blocked to the origin produces this error. Look at TargetConnectionErrorCount or its equivalent in your platform, because connection failures and slow responses need different fixes.

Step 3: Look at resource pressure

Microsoft's troubleshooting article for Azure Application Gateway names common causes: backend processing that runs past the configured request timeout, high CPU or memory, disk I/O pressure and network-level delay. On a typical website, that translates to:

  • A traffic spike that exhausts PHP workers or application threads.
  • A slow database query, often from a missing index or an unbounded report.
  • A plugin or script calling an external API that has stopped responding.
  • A backup, import or cron job running during peak hours.

Step 4: Read the logs

Match the time of a failed request to entries in your web server, application and database slow-query logs. Compare the target response time with the timeout configured on the gateway. If responses regularly approach the limit, you have found your problem. Our guide to website performance metrics for small businesses explains which numbers to watch.

Step 5: Fix the slow thing

Optimize the query, cache the expensive page, move heavy work to a background job, or add CPU and memory. Caching is often the cheapest win. If you publish with Ghost, this list of caching plugins for Ghost shows how others approach it. For wider tactics, see our speed optimization tips.

Step 6: Only then, consider the timeout

Sometimes a request really does need longer: a large export, a media upload or a payment provider callback. In that case a higher timeout is reasonable. AWS recommends raising it for time-consuming compute or external dependencies, not as a substitute for optimization. Its Application Load Balancer default idle timeout is 60 seconds.

Microsoft makes the same point for its own gateway. Azure Application Gateway defaults to a 20-second request timeout, and typical web application values run from 30 to 120 seconds. You can set it far higher, but values above 300 seconds do not cure an underlying backend or network problem. Those figures belong to Azure Application Gateway. Do not treat them as defaults for every host or server.

Step 6: Only then, consider the timeout — overview diagram

Why a bigger timeout is rarely the answer

A normal web page should not need minutes to build. If a request still times out at 120 seconds, or even beyond 300, the evidence points to backend latency or a network problem. A longer limit just makes visitors stare at a spinner for longer before they see the same error.

The better principle is the one in AWS's guidance: demonstrate that the system is healthy under load, then set a timeout that protects the legitimate long-running tasks. Treat the timeout as a safety net, not a repair.

Gateway timeouts behind a CDN

Searches for a gateway timeout with Cloudflare are common, because a CDN adds another hop. Cloudflare's documentation says a 502 or 504 means it could not establish contact with your origin web server, and that the response can come either from the origin or from Cloudflare itself.

A practical sequence:

  1. Look at the error page. Cloudflare says a branded error generally means the origin returned it, while an unbranded one can originate at Cloudflare. That is a clue about ownership, not proof of the root cause.
  2. Confirm the origin answers for the requested hostname. A virtual host that does not match the domain can look like a dead origin.
  3. Check for overload, crashes, network failures and blocked requests. Security software at the origin can mistake CDN traffic for an attack.
  4. Test the origin path directly, only if your setup allows it, such as temporarily bypassing the CDN for a test hostname.
  5. Collect evidence before contacting support. Cloudflare asks for the timestamp with time zone, the failing URL and the output of /cdn-cgi/trace.

The origin is the usual cause, so most of the fix still happens on your server.

Our perspective: what we see on managed hosting

We run the servers, so we look at 504s from the other side of the screen. In our experience, the pattern owners miss is that they chase the error code instead of the clock. A 504 is the end of a story that began earlier: a worker pool that filled up, a query that grew with the data, a backup that landed on top of a busy hour.

That is why we put the effort into prevention. Our plans include daily backups, free migration, automated security and a 30-day money-back guarantee, and our sites are looked after by SRE and DevOps engineers in the EU and US. A migration is a good moment to fix timeouts, since moving off an overloaded plan often clears them, but you should still find out why the old one choked. If you cannot find the cause in the logs, you will probably meet it again.

Our rules of thumb:

  • Monitor before you need to. You want to know about slow responses before a customer tells you. See our uptime monitoring guide and 360 Monitoring.
  • Treat reliability as a habit. Our uptime best practices for small businesses cover the routine.
  • Match the plan to the workload. Shared hosting suits modest sites. Sites that need guaranteed CPU and memory belong on a VPS or dedicated server.
  • Raise timeouts last, and write down why.

— Ihor

When your hosting plan is the bottleneck

Sometimes the code is fine and the plan is simply too small. Signs include 504s that appear at predictable busy hours, slow admin screens, and errors that disappear when traffic drops.

In that case, match the plan to the load:

Our free migration means you do not have to rebuild the site to move, and the 30-day money-back guarantee lets you test the new environment under real traffic. For the common causes and tuning options, our hosting optimization guide is a good next read.

What to send when you ask for help

Whoever you contact, a host, a developer or a CDN, you get a faster answer with specifics. Collect:

  • The exact failing URL, including any query string.
  • The date, time and time zone of at least one failure.
  • Whether it happens on every page or only some, and whether it is constant or intermittent.
  • What changed recently: a plugin update, a code deploy, a traffic campaign, a DNS change.
  • For CDN-fronted sites, the /cdn-cgi/trace output and whether the error page was branded.

This turns a vague complaint into something a support engineer can match to a log line.

FAQ

How do I fix a 504 gateway timeout?

As a visitor, reload, try a private window or another network, and turn off any VPN or proxy. As a site owner, identify which hop timed out, then check origin reachability, CPU and memory, slow queries and logs. Raise a timeout only after those checks, and only if the task needs more time.

Is a 504 error my fault?

Usually not. The delay typically sits between the gateway and the server behind it. The exception is a local VPN, proxy, firewall or DNS setting that interferes with your connection, which is worth checking if the site works for other people.

What does the 504 gateway timeout error mean?

It means a server acting as a gateway or proxy did not receive a response in time from an upstream server. The request path timed out, which is different from a 502, where the response arrived but was invalid.

Does a 504 gateway timeout mean the website is down?

Not necessarily. One request path failed. The page may load on the next try, or only one endpoint or region may be affected. If every page fails repeatedly, treat it as an outage and contact the site owner or host.

Sources