A 504 Gateway Timeout error means one part of a website waited too long for another part to answer.
The website may be waiting for WordPress, a database, a payment service or another online system. When the answer does not arrive in time, the service at the front stops waiting and shows 504.
This article is part of our Common Web Server Errors Explained series.
The short version
If you are a visitor, wait and try again once. Be careful when retrying payments or forms because the original request may still have completed.
If you run the site, find the slow step before increasing the timeout. A longer wait does not make a slow database query or failing external service healthy.
What does a 504 Gateway Timeout mean?
Modern web requests often travel through several services. A CDN contacts the main website server. NGINX passes a request to the service running PHP. The application then asks a database for information or contacts another company's system through an API.
Each layer has a limited amount of time it will wait for the next. If the service behind it-known technically as the upstream service-does not respond in time, the middle service stops waiting and returns 504.
The upstream service may still be running. It may even finish the task after the visitor has already received the error. The problem is that it did not complete within the expected request window.
Common causes of 504 errors
Slow database queries are a frequent cause. Missing indexes, locked tables, large reports and overloaded database servers can hold an application request beyond the proxy timeout.
Slow PHP or application code can do the same. Imports, image processing, complex page builders, large searches and poorly optimised loops may take too long to complete.
External APIs introduce dependencies outside the hosting environment. A payment, shipping, CRM or licensing service may respond slowly or not at all. If the application does not use sensible connection and response timeouts, one vendor can hold the entire page request open.
Worker exhaustion can look like slowness even when individual code paths are acceptable. New requests wait in a queue because every PHP or application worker is busy.
Network and DNS problems between services are less common but possible. The gateway may struggle to resolve or connect to an upstream host.
Scheduled tasks and traffic spikes can create intermittent timeouts. A backup, report or WooCommerce action scheduler job may compete for the same database and CPU resources used by visitors.
504 vs 502 and 503
A 502 Bad Gateway usually means the gateway received an invalid response or could not establish a usable connection with the upstream.
A 503 Service Unavailable says the service cannot handle the request at the moment.
A 504 specifically describes waiting too long for the next service to respond. Platforms do not always use every error code in exactly the same way, but 504 points the investigation towards a slow or blocked process.
How to diagnose a 504 error
Record the exact URL, timestamp and action. A timeout while loading every page has a different cause from one that occurs only when exporting a report or completing checkout.
Identify which gateway returned the response. Response headers, error-page branding and request IDs can distinguish a CDN timeout from one generated by the origin web server.
Review gateway logs for the upstream address and measured response time. Then inspect the application, PHP and database logs for the same request window.
Use application performance data to break the request into components. How much time was spent waiting for PHP, a database query, DNS, an HTTP API or file storage? A total page time does not explain the delay.
Check resource and queue metrics. High CPU, memory pressure, saturated PHP workers or a large database connection queue provide useful context. Look for scheduled jobs and traffic changes at the same time.
When the problem is intermittent, collect several examples. A single timeout can be a transient dependency failure; a recurring pattern often reveals a specific endpoint or schedule.
How to fix a 504 Gateway Timeout
Optimise the slow operation rather than starting with the gateway. Add appropriate database indexes, correct inefficient queries, reduce repeated API calls and cache results that do not need to be generated for every visitor.
Move long-running work out of the browser request. Imports, reports, email delivery and bulk processing are usually better handled by a background queue with progress reporting.
Set short, deliberate timeouts around external services and handle failure gracefully. A website should not wait indefinitely because a non-essential vendor API is slow.
If workers are saturated, profile the workload and size the pool within the available memory. More workers may help legitimate concurrency, but too many can exhaust the server.
Increasing proxy timeouts may be justified for a known operation that genuinely needs more time and cannot yet be redesigned. Treat it as a conscious exception, not a universal fix. The user experience of waiting several minutes still needs attention.
After making changes, reproduce the original workflow and measure each stage. A request that no longer reaches the timeout but remains unreasonably slow is not fully resolved.
504 errors in WordPress and WooCommerce
WordPress timeouts frequently involve plugins making remote requests, slow database queries, scheduled actions and resource-heavy administration tasks.
WooCommerce checkouts depend on payment, tax, shipping, inventory and other services. If one integration is slow, the customer may receive a 504 even though the order or payment later completes. This creates a serious risk of duplicate attempts, so payment state must be checked before retrying.
Large WordPress imports, backups and image operations should not rely on one browser request remaining open. Use tools that process work in batches or through a queue.
The public site may appear fast because its pages are cached while /wp-admin, account pages and checkout time out. Test dynamic workflows directly instead of assuming a quick homepage proves the application is healthy.
Review WordPress scheduled actions, database query performance, PHP worker usage and outbound HTTP calls. Disable or roll back a component only when evidence points to it, preferably in staging.
Is a 504 a hosting issue or an application issue?
The gateway timeout is enforced by infrastructure, but the delay often originates in the application or one of its dependencies.
Your hosting provider should be able to identify the gateway, upstream target, timeout value, worker saturation and server resource state. They are responsible for correcting platform bottlenecks and appropriately sizing infrastructure.
The website owner or developer is responsible for slow code, database queries, plugin behaviour and external API handling. A larger server may reduce symptoms without correcting inefficient work.
Some fixes are collaborative. Hosting data can show which request is slow, while development tracing explains why. The best outcome improves the application and retains sensible infrastructure safeguards.
How to prevent future 504 errors
Monitor response time by endpoint and separate gateway time, application time, database time and external calls. Average page speed can hide a small number of critical timeouts.
Set performance budgets for important workflows. Test checkout, login, search and administration functions under realistic load, not only public cached pages.
Use background queues for long work and caching for results that can be reused. Applications should also stop repeatedly calling an external service that is already failing. Keep database maintenance, indexes and capacity under review as data grows.
Schedule heavy tasks away from peak periods and prevent several jobs starting together. Alert on worker queues and slow queries before they reach the gateway timeout.
For WordPress, keep plugins and PHP maintained, remove abandoned components and review scheduled actions. Document any deliberately extended timeout and the business reason for it.
Frequently asked questions
Is a 504 caused by slow internet?
Usually not. It is generated because a gateway waited too long for an upstream service. A client connection problem more commonly produces a browser or request timeout.
Will refreshing fix a 504?
It may work after a temporary delay, but be cautious with payments and form submissions. The original request may have completed after the browser received the error.
Should I increase the timeout?
Only after identifying the slow operation. Longer timeouts can be appropriate, but they can also hide a database, API or code problem and worsen worker saturation.
Can a WordPress plugin cause a 504?
Yes. Plugins can run slow queries, make blocking external calls or start resource-heavy work during a request.
Can a CDN cause a 504?
A CDN can return the 504 when its origin does not respond in time. The root cause may be at the origin, in the network path or in CDN configuration.
Does a 504 affect SEO?
Short incidents are unlikely to cause lasting damage. Frequent timeouts prevent crawling and harm user experience, particularly on important landing pages.
Final thoughts
A 504 Gateway Timeout is a performance failure expressed as an availability error. The request path remained open, but something upstream did not finish in time.
Increasing the clock is rarely the most useful first move. Trace where the time was spent, correct slow or blocked work and reserve longer timeouts for genuine business requirements.
At Network Dynamics, our engineers can help diagnose the error, explain the cause in plain English and recommend a practical next step. You will not be left wondering whether the delay sits with the hosting platform, PHP, the database, WordPress or an external service-or whether the solution is optimisation, development work or additional capacity.
Continue with What Is a 508 Loop Detected Error?, or return to Common Web Server Errors Explained.
