How to Diagnose a 504 Gateway Timeout
504 Gateway Timeout means one server gave up waiting for another. Trace the slow upstream server, apply a safe fix, and confirm it like a visitor.
By Matthew Zhao · Editor, Hosted EZ
A 504 Gateway Timeout means one server gave up waiting for another. When a proxy, load balancer, or CDN sits in front of your site, it forwards each request to an upstream server and waits for the reply; if that reply takes too long, it returns HTTP 504 instead of a page. Diagnosing one is mostly about finding which hop is slow.
This guide covers the checks a small-site owner can make safely, and where a host or developer needs to take over. Read how to choose a web host if timeouts keep pushing you toward a new provider, and our migration guide before changing live infrastructure.
Record what the 504 Gateway Timeout looks like
Start by recording the exact status code, URL, time, and whether the timeout affects every page or only heavy ones such as search, checkout, or admin screens. A gateway timeout error on heavy pages only usually points at slow application code or database queries rather than a dead server.
Make a short note with account names, domain names, the exact URL involved, and the last known working time. Do not put passwords or recovery codes in the note. You want enough detail to retrace the work without creating a new security risk.
Find the slow upstream server
Check recent changes, resource usage, and logs before restarting things at random. A 504 nearly always means the service behind the proxy is alive but slow: an exhausted database, a hung PHP process, or an external API call that never returns. Each of those looks identical from a browser.
Use a private browser window or a separate device after a change. If a CDN or proxy sits in front of your host, test the origin directly where your host allows it, so you can tell which layer is timing out.
Test the result like a visitor
Make the smallest safe correction, then test again from a fresh browser session. If it does not change the symptom, revert it and move to the next theory. Keeping that discipline prevents a second problem from hiding the first.
Test the normal path first, then the part that has the most consequence. For a store, that is checkout. For a form, it is receiving the email. A test should answer one question rather than produce a vague impression.
When to hand an HTTP 504 to your host
Stop when the next action could overwrite data, change production mail, or remove access to the account. Raising a timeout limit hides the slowness rather than fixing it, so if you cannot see what is slow, hand it over: send support the domain, time in UTC, the exact error, and the changes you made. Include a screenshot when it shows the error, but not private keys, passwords, or payment information.
MDN's HTTP status reference explains how a 504 differs from a 502 or a plain 500: MDN's HTTP status reference. Use it to understand the terms, then return to the small, reversible next step.
A sensible maintenance habit
Put the layer that timed out and the fix in a short maintenance note. Timeouts repeat because nobody remembers whether the culprit was the database, a plugin, or an external API last time. A dated note turns the next incident into a lookup instead of an investigation.
Keep the change auditable
Write down the setting you found, its old value, the exact time you changed it, and the result of the test. If the change has a delay, such as a cache expiry, write the time you expect the new behavior to be visible. A few months later, this record tells you why a timeout value is set the way it is.
Do not confuse an account dashboard with evidence from the live site. A dashboard can show a healthy server while requests through the proxy still time out. Test from outside the account, and use a second connection if a cached answer could mislead you.
One last check
Before you close the ticket, repeat the slowest request the way a visitor would, not through the dashboard. Timeouts scale with load, so check again during your busiest hour; a page that just squeaks under the limit when the site is quiet will fail when it is not.
Leave a useful handoff
Save the final test result with the date and account involved. If the timeout returns, whoever picks it up should see which layer was slow last time without reconstructing the incident from browser history.
Bottom line
A 504 Gateway Timeout gets easier when you work out which upstream layer is slow, make one reversible change, and test the result where it matters. Keep evidence, resist the urge to just raise the timeout, and hand the ticket to your host before a safe step turns into a data-loss risk.
Frequently asked questions
Should I change several timeout settings at once?
No. Change one related setting, test it, and keep the previous value until you know the result is stable.
What should I tell hosting support about a 504 Gateway Timeout?
Give the domain, exact URL or service, UTC time, error text, and steps already tried. That is usually enough for support to find the slow request in their logs.
Should I keep a backup before this work?
Yes. Download or verify a recent backup before edits that affect files, databases, server configuration, or software versions.
About the author
Matthew Zhao
Matthew has spent his career running production server fleets — tens of thousands of machines' worth. He writes about hosting the way he wishes someone had explained it to him: plainly.
About Hosted EZ →Get the next guide in your inbox
One email when we publish something worth your time. No spam, unsubscribe whenever.
