A WordPress 504 error means a gateway or proxy waited too long for your server to respond. To fix it, identify whether the delay comes from WordPress, your hosting server, or an intermediary proxy.
Start with reversible checks before editing files or increasing limits. Repeat the same failing request after each change so you can tell which fix worked.
Key Takeaways
- Test another connection and review hosting status before changing WordPress.
- Back up your files and database before disabling plugins, switching themes, or editing settings.
- Use matching timestamps in server logs to identify the delay. Increasing timeouts can temporarily hide an overloaded server.
What a WordPress 504 Error Means
A 504 Gateway Timeout is a server-side HTTP error. A gateway received your request but didn’t get a timely response from another server.
Your request might pass through Cloudflare, Nginx, PHP-FPM, and WordPress. Any slow or unavailable component along that path can interrupt it. Gateway-error documentation explains how origin-server failures can produce gateway errors.
Browser messages vary. Chrome may show “This site can’t be reached” and “website took too long to respond.” Firefox may display “504 Gateway timeout” and “the server didn’t respond in time.”
However, Chrome’s generic connection message alone doesn’t establish a 504. Record the actual HTTP status when available.
1. Rule Out a Temporary or Local Problem
Test the same URL elsewhere
Refresh once, then open the affected URL in a private window. Try mobile data, another internet connection, or Website Planet’s website checker.
If it works elsewhere, investigate your browser, local DNS, VPN, or network. If it fails across connections, focus on your website’s infrastructure.
Compare your homepage with /wp-admin/ and the operation that failed. A working homepage doesn’t prove that checkout, uploads, or uncached requests work.
Avoid repeatedly submitting payments because a timeout doesn’t prove the transaction failed.
Clear your local DNS cache
On Windows, open Command Prompt and run ipconfig /flushdns to flush DNS on that computer. You’ll receive a confirmation such as “Windows IP configuration successfully flushed the DNS resolver cache.”
Then reopen your browser and retry.
After a DNS change, cached records can remain until their TTL expires. Flushing your computer’s DNS cache doesn’t clear your ISP’s resolver cache or fix incorrect authoritative DNS records.
2. Check Hosting, Cloudflare, and Cached Responses
Check your host’s status page. If Cloudflare appears on the error page, use its status-page guidance to check for incidents or scheduled maintenance.
A branded error page doesn’t prove the proxy caused the failure. It can relay a 504 from your origin server. Without a CDN or another external proxy, investigate your host first.
Clear your browser cache, then purge relevant WordPress, hosting, and CDN caches. Use your hosting controls if the dashboard won’t load.
Ask your host to test the affected URL directly at the origin while preserving its hostname and TLS configuration. If the origin works but the CDN route fails, investigate that connection. If both fail, focus on the origin.
Retest an uncached request, not just your homepage. Our WordPress performance guide explains why caching helps public pages more than dynamic operations.
3. Isolate Plugins and Your Theme
First, preserve your files and database through your host’s backup system. Use staging or session-only troubleshooting when available, since disabling plugins can interrupt forms and checkout.
Disable plugins without dashboard access
Connect through SFTP or your hosting file manager. Inside wp-content, rename plugins to plugins.disable, then repeat the failing request.
If the error disappears, restore the directory name. Rename individual plugin folders one at a time, testing after each change. If WordPress has deactivated everything, reactivate plugins individually instead.
Start with outdated plugins and any recently installed or updated plugins. Our guide to finding WordPress plugin conflicts covers safer isolation methods.
Confirm a plugin conflict by reproducing the failure with the suspected plugin enabled and checking that it clears when the plugin is disabled. Ordinary plugin-folder testing doesn’t disable must-use plugins or hosting-level components.
Test a default theme
If plugins aren’t responsible, temporarily activate an installed default theme, such as Twenty Twenty-Five, under Appearance > Themes.
Repeat the original request and compare results. A successful test points to your previous theme or its interaction with another component.
Restore unaffected plugins afterward. For staging vs live comparisons, check PHP versions, resource limits, traffic, and scheduled jobs, since differences can affect the result.
4. Review Resource Limits and Timeout Settings
Match PHP changes to the failure
Inspect hosting metrics for CPU, memory, PHP workers, and database connections. Compare them with the capacity in your hosting plan to see whether resource usage limits are being reached. Heavy traffic can produce a 504 even when a 503 would describe overload more accurately.
In Hostinger’s PHP options, its troubleshooting guidance lists a 30-second default for PHP max execution time. Try 60 seconds, then 120 to 180 seconds if necessary.
Treat this as a temporary measure. Reduce import or backup batch sizes and investigate slow queries or external API calls.
Only raise memory_limit when logs show memory exhaustion. WordPress memory constants can’t override your host’s enforced ceiling.
Keep gateway timeouts separate
PHP’s max_execution_time controls how long PHP runs, while a server timeout controls the gateway or web server. PHP-FPM’s request_terminate_timeout and web-server timeouts control different stages. Raising one doesn’t change the others.
For self-managed Nginx, relevant settings include fastcgi_read_timeout 120s; for PHP-FPM or proxy_read_timeout 120s; for a proxied backend. Apache reverse-proxy configurations may use ProxyTimeout 120.
Change only the applicable setting. Validate Nginx with sudo nginx -t before reloading it with sudo systemctl reload nginx.
Don’t paste generic php_value directives into .htaccess; incompatible PHP setups can return a 500, and Nginx ignores that file.
A longer timeout can let a slow request finish while also tying up a worker for longer. Confirm that normal requests remain responsive.
5. Inspect Error Logs and Disk Space
Collect evidence without exposing errors
Reproduce the failure once and note the time and timezone. Inspect matching server and PHP log entries for upstream timed out, memory exhaustion, or database failures.
On Hostinger, PHP error logging is disabled by default. Enable the log errors checkbox under hPanel’s PHP options, then inspect the generated error log in public_html.
For temporary WordPress debug logging, edit existing definitions in wp-config.php: define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true);, and define('WP_DEBUG_DISPLAY', false);.
Protect the log from public access before testing. After diagnosis, turn logging off with define('WP_DEBUG', false);, define('WP_DEBUG_LOG', false);, and define('WP_DEBUG_DISPLAY', false);.
Save relevant excerpts securely, then delete /wp-content/debug.log. Freshy’s documented troubleshooting case involved a log exceeding 1GB. Fix the cause of repeated PHP warnings, or the log will grow again when re-enabled.
Check whether storage is full
With SSH access, run df -h for filesystem capacity and df -i for inode usage. To inspect WordPress storage, run du -h --max-depth=1 wp-content.
If disk storage is full, identify and remove disposable files, then repeat the failing request.
In the Cleavr forum case, MySQL binary logs filled the disk. The SQL form for controlled cleanup is PURGE BINARY LOGS BEFORE 'YYYY-MM-DD HH:MM:SS';, with an administrator-selected retention cutoff.
Don’t delete binary logs manually. Purging can break replication or point-in-time recovery. A commenter reported success with disable_log_bin, but disabling binary logging can remove those capabilities.
6. Investigate Database, Update, and Routing Problems
If logs identify a corrupted database table, back up the database before attempting repairs. Theme.co’s discussion suggests using WP-DBManager’s Repair DB, followed by Optimize DB. Repair only supported tables when there’s evidence of corruption.
After a WordPress reinstall or migration, inspect .htaccess on Apache or LiteSpeed for unexpected rules. Save a copy before testing changes. Don’t replace custom redirects or security rules blindly.
If bulk plugin updates trigger timeouts, follow the approach described in Freshy’s case: enable maintenance mode, update one plugin or a small batch, and clear relevant caches between batches. Schedule updates during low-traffic periods.
Check that each update completed before continuing. A 504 doesn’t establish whether an update succeeded or failed.
Then disable maintenance mode and retest the dashboard, frontend, and previously failing action.
7. Contact Your Host With Useful Evidence
Contact your host right away if every request fails, storage is full, or logs show unavailable server services. You don’t need to finish every WordPress test first.
Send hosting customer support the affected URLs, when the problem started, timestamps with timezone, recent changes, and every fix you’ve tried. Include redacted log excerpts and a Cloudflare Ray ID when available.
Ask them to inspect worker saturation, PHP-FPM, slow queries, cron jobs, and outbound DNS resolution. Your application must resolve every external domain it depends on.
Also ask whether firewall or DDoS rules block CDN traffic. Community troubleshooting advice identifies blocked provider IP addresses as a possible cause.
Frequently Asked Questions
Does a 504 mean your WordPress site was hacked?
A 504 alone isn’t evidence of hacking. Overload, slow code, and connectivity failures can produce the same error.
If you also find unfamiliar administrator accounts or modified files, investigate those signs separately.
Is deleting debug.log safe on a live site?
Yes, after preserving useful diagnostic evidence and disabling logging. Deleting it doesn’t remove posts, orders, or settings.
However, it won’t fix the code producing repeated warnings. Keep any retained copy private because logs can contain sensitive information.
Is a 504 the same as a 500 error?
No. A 504 identifies a gateway wait that expired. A 500 reports a broader internal server failure.
If your response changes to 500, follow our WordPress 500 troubleshooting guide using the new log evidence.
Restore Service and Confirm the Fix
A reliable fix survives the original failing request, not merely a cached homepage load. Test login and affected forms, and use payment test mode for checkout.
Restore unsuccessful changes and turn off temporary debugging. Keep the responsible component disabled until you’ve repaired or replaced it.
Your strongest evidence is a repeatable result tied to one controlled change.
