A page that waits and then returns 504 indicates a gateway did not receive its upstream response in time. A checkout or import may still finish behind the error page, so check its result before retrying.
Compare cached and dynamic requests, match the failure with server logs and reduce work in the request that actually stalls.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Pattern | Next check | Why it helps |
|---|---|---|
| Export fails but ordinary dynamic pages work | Export stage and query timing | Focuses the slow operation. |
| Cached homepage works; dashboard fails | PHP workers and dynamic request logs | Cache can hide an origin failure. |
| Checkout waits on an external provider | Outbound destination and timing | Separates third-party delay from local work. |
| Many unrelated requests fail together | Server health and worker availability | Tests shared resource contention. |
Find the pattern before changing a timeout
Try a normal public page and a dashboard page, then compare them with the action that failed. If a large export times out but other pages respond promptly, focus on the export. If unrelated pages fail together, your host should check the server’s health and available workers.
Note the time, URL, approximate wait, and wording of the error page. A request identifier can help your host find the matching log entry. The page design sometimes suggests which proxy returned the error, but the logs are a better way to establish which layer stopped waiting.
A cached homepage loading successfully does not prove WordPress is healthy. That page might be served without running PHP at all. A simple dynamic page or an authenticated dashboard request gives you a more useful comparison.
What was the upstream server doing?
Log question: ask whether the upstream accepted the request, queued it or remained busy without sending a response. Give the host the timezone, path and request identifier. Keep customer data and credentials out of shared reports.
Your host can match the failed request with web-server and PHP-FPM logs. The question is whether the upstream process accepted the request, remained busy, or never became available. This separates a slow application from a connection or worker problem.
For example, an export may spend a long time gathering database records before sending any response. A checkout extension may wait for a shipping service. During a traffic spike, otherwise ordinary requests may wait behind busy PHP workers. These cases can all look similar in the browser, but need different repairs.
If the host identifies a slow database query, share the relevant plugin or theme context with its developer. If an external service is involved, compare its status and the destination request’s timing. Our guide to cURL request timeouts explains how to narrow down those outbound failures.
Reduce the work in one request
- Check whether the previous attempt completed.
- Run a smaller representative task.
- Record progress and the last completed item.
- Use supported resumable processing if the complete job exceeds a single request’s practical duration.
Imports, image processing, and backups often benefit from smaller batches or resumable background jobs. A tool that processes a few hundred items at a time has more opportunities to save progress than one that holds a browser request open for the entire library.
Check the job’s progress before restarting it. If it always stops on the same item, examine that item and any repeated retries. A broken loop will not become a good workflow simply because the proxy waits longer.
Plugin conflict testing can help when the issue began after a specific change. Use a staging copy for checks that could affect a store, forms, or memberships. Keep the same test action each time so you can tell whether the change made a difference.
When adjusting the server limit makes sense
A legitimate operation sometimes needs a longer allowed wait, but the setting must belong to the layer producing the error. PHP’s max_execution_time is separate from a web server’s upstream timeout. Raising one does not automatically raise the other.
Nginx, for example, documents fastcgi_read_timeout as a limit between successive reads from the FastCGI server, rather than a deadline for the entire response. Other proxies have their own rules. Your hosting provider can confirm which setting applies and whether its managed service allows an adjustment.
Longer waits also keep resources occupied for longer. Before changing them, establish that the task is making progress and that the server can handle it. If a resource shortage is the cause, an increased timeout may only leave more requests waiting.
Confirm the action, not just the page
After the repair, repeat the affected action once and verify its result. An export needs a complete file, a backup needs a usable archive, and a checkout needs one correctly recorded order. Then check another dynamic page to make sure the fix did not merely move the delay elsewhere.
If the server returns 503 Service Unavailable or a 502 Bad Gateway response instead, follow those symptoms separately. For reference, see MDN’s explanation of HTTP 504 and the Nginx FastCGI documentation.
Confirm output and dynamic page health
Verify a complete export, usable backup or single test order as appropriate. Then check another dynamic page and fresh logs. A longer wait is useful only when the legitimate task progresses and the responding layer supports that adjustment.