WordPress 504 gateway timeout: causes on shared hosting

Most 504s on shared hosting trace back to one of three things: a slow plugin operation, a slow database query, or a PHP limit set too low for what the page is doing. A 504 gateway timeout means the web server gave up waiting for PHP to finish generating the page; something upstream took too long and LiteSpeed cut the connection before it got a response. Reload the page first: a single slow request (a big import, a stuck cron job) causes plenty of 504s without pointing to a permanent problem. If it keeps happening, work through the three causes below in order; they cover most 504s on shared hosting.

1. A plugin or theme is running a slow, blocking operation

This is the most common cause. A plugin doing an import, a report generation, or an unthrottled API call to a third-party service can hold PHP open past the timeout. Check what changed recently: a new plugin, an update, or a bulk action (import/export, migration, search-and-replace) you just ran.

To isolate it, the same disable-and-test approach used for the white screen of death works here: rename /wp-content/plugins/ to /wp-content/plugins.bak/ via FTP or the file manager, reload the page, then restore and disable plugins one at a time from wp-admin → Plugins until you find the one that hangs. If the 504 only happens on a specific admin screen (WooCommerce reports, a page builder editor), that narrows it to the plugin behind that screen.

Plugins that call external APIs on every page load are a frequent culprit: license checks, stock feeds, shipping-rate lookups. If the third-party API is slow or down, your page load waits on it. Look for a setting to cache or defer that call, or disable the feature until the plugin vendor fixes it.

2. A slow or locked database query

If disabling plugins doesn't fix it but the timeout happens on pages that hit the database hard (search results, large archive pages, WooCommerce checkout), the query itself is probably the bottleneck. Two common patterns:

• Autoloaded option bloat. WordPress loads every wp_options row marked autoload = 'yes' on every request. Years of plugin churn can leave that table holding tens of megabytes of dead settings, which slows every single page load before your content even starts rendering. See optimizing your WordPress database for how to check and trim it.
• A locked table from a stuck process. A cron job or import that died mid-write can leave a table locked, so every subsequent query queues up behind it. If you have shell access, check for long-running queries via phpMyAdmin's status page.

Revisions add up the same way: a post edited hundreds of times can carry hundreds of rows in wp_posts, and a query that scans all of them on load gets slower every year. Capping revisions is covered in the same database article above.

3. PHP resource limits are too low for what the page needs

Some pages genuinely need more time or memory than the defaults allow: a large image being processed on upload, a big CSV import, a page builder saving a complex layout. If the delay is real work rather than a bug, raise the relevant limit rather than fighting it.

max_execution_time and memory_limit are set in cPanel under Software → MultiPHP INI Editor. Switch to Editor mode, select the location (your home directory or the domain's docroot), and raise max_execution_time and memory_limit if the operation is memory-heavy too. This is separate from the PHP Version tile in the portal: that only switches the PHP version itself (7.4 through 8.3), not its resource limits.

If you recently changed PHP versions and the 504s started right after, roll back from the PHP Version tile under Services → your hosting and confirm whether that's the trigger. A plugin built for an older PHP version can behave very differently, including running much slower, on a newer one.

Worth ruling out: on most hosting accounts, WP_DEBUG_LOG writes to /wp-content/debug.log even on a 504, since PHP was still executing when it logged. Turning it on briefly, as described in the white screen of death article above, often shows exactly which function was running when the request got killed.

When to open a ticket

If you've ruled out a specific plugin, cleaned up the database, and raised the PHP limits but a legitimate page still can't finish in time, that's a sign the operation needs to move off the request cycle entirely: a background job instead of a live page load. That usually means a code or architecture change on the plugin's side. Open a ticket from Support → New ticket in the portal with the exact URL that times out and roughly when it started. A real person can check server-side logs for the request and confirm whether it's a resource ceiling, a stuck process, or something worth escalating to the plugin developer.