504 Gateway Timeout means the go-between (Nginx, a load balancer or a CDN) waited for the program behind it and gave up before it answered. Unlike a 502, the backend is usually running. It is just too slow, or stuck.
If you are visiting the site
Wait a minute and reload. If the page does something heavy, such as an export or a large search, it may keep timing out until the site owner fixes it.
If you run the site
1. Find which requests time out
sudo grep 'upstream timed out' /var/log/nginx/error.log | tail
The log lines include the URL. Is it every page, or one slow page? One page points to slow code or a slow query; every page points to an overloaded server.
2. Check whether the server is overloaded
uptime
top
A load average well above your CPU count, or memory nearly full, means the server cannot keep up. Add page caching (see caching), or more resources.
3. Look for slow database queries
On MySQL or MariaDB, list what is running right now:
sudo mysql -e 'SHOW FULL PROCESSLIST;'
Queries running for many seconds are the usual culprit. Turning on the slow query log shows them over time.
4. Check external calls
Pages that call another service (a payment API, a feed, a licence check) wait for it. If that service is slow, your page is slow. Add timeouts to those calls in your code.
5. Raise timeouts only for genuinely long work
If a task really needs longer, such as a large import, raise the limits together:
# Nginx, inside the PHP location block
fastcgi_read_timeout 300;
# PHP-FPM pool
request_terminate_timeout = 300
# php.ini
max_execution_time = 300
Reload Nginx and restart PHP-FPM afterwards. For proxied apps, the Nginx setting is proxy_read_timeout. Do not raise timeouts across the whole site to hide a slow page; visitors still wait.
Related
- 502 Bad Gateway: the backend failed rather than ran slowly.
- How much RAM a site needs.
Something out of date? Software changes. If a step no longer works, tell us and we will check it and update the page.



