How to fix the 504 Gateway Timeout error in WordPress

Look for its result: the imported posts, a backup file with today's date, the new version numbers. If everything is there, nothing is left to do. If only part is, find out from the tool's documentation whether a second run carries on or starts over.

How to use WP-CLI to manage a WordPress site covers connecting, checking that WP-CLI is installed, and backing up the database before a command that writes.

A backup, a sync or a feed import that runs by itself each night is a scheduled event. List them:

The first column, hook, is each job's name. Look for the one that carries the plugin's name.

Put the job's name in place of hook-name. The command runs the next scheduled event for that hook and prints whatever the job reports. It ends with "Executed the cron event", the time it took, and "Success: Executed a total of 1 cron event." Keep the window open until then.

WP-CLI has commands for updates, database exports and replacing an address. In the WP-CLI command builder you choose a job, fill in what it needs, and copy the command with its flags in place. A plugin can add commands of its own, so look in the documentation of the plugin that does the job.

Update one plugin at a time, not all of them at once.

Select fewer items each time, so that each request finishes.

Split a large import file into several smaller ones, or use the tool's own setting for the size of a batch if it has one. WordPress's export screen can export posts or pages alone, and one range of dates at a time.

If the backup plugin can split its work into smaller steps, turn that on.

One page, one kind of page (a search, a report, the checkout), or only the dashboard. A page that fails only at busy hours points at the server, not the page.

The page that answers 504 shows you nothing, so measure one like it that is slow but loads. How to reduce server response time (TTFB) in WordPress shows how to time a request in phases, with the cache and without it, and how to see which plugin, query or outside request a page spent its time on.

WordPress waits up to 5 seconds by default for each call it makes to another server, and a plugin can ask for longer. A page that calls a service that is down waits out each call. If the slow pages all use one outside service, check whether that service is up.

How to find and fix a WordPress plugin conflict covers switching plugins off and bringing them back in halves.

nginx writes a line with "upstream timed out" to its error log. If the log has no such line at the time of the 504, the wait that ran out belongs to something further forward, such as a load balancer or a CDN.

The first set of tabs below has the line. In nginx, put it in the site's server block, inside the location block that holds fastcgi_pass or proxy_pass. Both waits are 60 seconds by default, counted from the last time the server behind sent anything. In Apache, put it in the site's virtual host: it is not allowed in .htaccess. Unless it is set, ProxyTimeout takes the value of Timeout, which is 60 seconds by default.

Use the second set of tabs. The first command checks the files, and the second runs only if the check passed.

A long wait lets a stuck request hold on to the server for five minutes at a time. If the job now ends in "There has been a critical error on this website", PHP's own limit was reached, and the page linked at the top of this one covers raising it.

The full address that failed, the exact time with your time zone, the words on the error page, and what you were doing.

Ask which server answered 504 and how long it waits. Ask what the error log shows for that request, and whether the server was under heavy load or the account had reached a limit. If one long job is the cause, ask whether the wait can be raised for your site.