Meta description
How I diagnosed and fixed a WordPress 504 Gateway Timeout on OVH hosting caused by an Elementor plugin conflict, background processes, and leftover cache configuration.
URL slug
wordpress-504-elementor-ovh-fix
Case Study
Fixing a WordPress 504 Gateway Timeout and Elementor Conflict on OVH Hosting
A client running a WordPress website for a French artisan food business contacted me after the entire website suddenly became almost unusable.
The frontend was returning 504 Gateway Timeout errors, and even /wp-admin/ had become extremely slow and unreliable.
The issue appeared shortly after Elementor had been reactivated, so Elementor initially looked like the obvious cause. However, the server logs showed that several processes were happening at the same time, making the real problem more complicated.
The Problem
The WordPress website was hosted on OVH shared hosting and was experiencing:
- 504 Gateway Timeout errors
- Extremely slow WordPress admin
- Intermittent database connection problems
- Long-running PHP requests
- Repeated Action Scheduler AJAX requests
- Background monitoring and security activity
- Leftover caching configuration from a previously disabled optimization plugin
Some requests were taking well over a minute to complete, which can quickly exhaust PHP workers and available resources on shared hosting.
Initial Investigation
I started by checking the OVH server logs and connecting to the hosting account through SSH.
The logs showed repeated requests to:
wp-admin/admin-ajax.php?action=as_async_request_queue_runner
There were also background calls from monitoring, caching, scheduled actions, and security-related processes.
Instead of immediately reinstalling WordPress or changing hosting, I tested each layer separately.
Database test
A direct WordPress/MySQL query completed in approximately:
0.11 seconds
This showed that the database server itself was responsive.
Static file test
A simple static HTML file loaded in roughly:
0.6–1 second
Basic PHP test
A standalone PHP file also responded in approximately:
0.6–0.7 seconds
This confirmed that OVH’s web server and PHP handler were working correctly.
The problem was therefore happening inside the WordPress application stack.
Cache Configuration Issue
The Seraphinite Accelerator plugin had already been disabled, but WordPress was still loading its:
wp-content/advanced-cache.php
drop-in.
There were also Seraphinite-generated rewrite rules remaining inside .htaccess.
I safely backed up the configuration and removed the leftover cache integration so that a disabled plugin was no longer executing code on every WordPress request.
Action Scheduler Investigation
I also inspected the Action Scheduler database tables directly.
There were failed and pending scheduled actions from several plugins, including background jobs associated with monitoring and form processing.
The queue itself was not large enough to explain the entire outage, but some stale actions and background execution were adding unnecessary load while the website was already struggling.
I temporarily stopped the asynchronous Action Scheduler runner while troubleshooting.
Elementor Was the Trigger — But Not the Whole Story
When Elementor was removed from the active plugin stack, WordPress immediately became much faster.
A WordPress bootstrap test that had previously timed out completed in approximately:
0.5 seconds
At first, this suggested Elementor itself was responsible.
I tested multiple Elementor versions, including earlier releases, but the slowdown continued.
That was an important clue.
Instead of continuing to downgrade Elementor, I began isolating other plugins that interacted with it.
Finding the Actual Conflict
I disabled the remaining plugins and reintroduced them selectively.
The key conflict was eventually traced to an Elementor-related plugin:
BWD Social Icon
With Elementor running normally and BWD Social Icon disabled, the website remained responsive.
When BWD Social Icon was activated again, the website became noticeably slower.
The plugin was therefore left disabled, as its functionality was not essential to the site and could easily be replaced using Elementor’s own social icon features if required.
Additional Cleanup
During the repair I also:
- Removed obsolete cache integration
- Checked WordPress cron behavior
- Investigated Action Scheduler jobs
- Temporarily stopped unnecessary background requests
- Inspected active and inactive plugin states
- Tested different Elementor versions
- Verified database responsiveness
- Checked the server independently from WordPress
- Restored the required plugin stack
- Tested both the frontend and WordPress admin area
Result
After isolating the problematic plugin combination and cleaning the background/cache configuration:
- The 504 Gateway Timeout stopped
- WordPress admin became responsive again
- Frontend pages loaded normally
- Database response remained healthy
- Elementor could continue to be used
- No hosting migration or WordPress reinstall was required
The important part of this repair was not simply disabling Elementor.
The issue required separating the hosting layer, PHP layer, database layer, WordPress core, background jobs, caching system, and plugin stack until the actual conflict became reproducible.
Key Takeaway
When a WordPress site starts returning 504 errors after a plugin update, the plugin that was updated is not always the complete root cause.
A combination of:
plugin conflicts + background processes + cache leftovers + limited shared-hosting resources
can turn a relatively small compatibility issue into a complete site outage.
Systematic troubleshooting is much safer than randomly disabling plugins, restoring old backups, or immediately moving to a new server.
Need help with a slow or broken WordPress site?
I troubleshoot WordPress issues involving:
- 500 / 502 / 503 / 504 errors
- Elementor problems
- Plugin conflicts
- Slow wp-admin
- WordPress cron and Action Scheduler
- Database performance
- Cloudflare / DNS / SSL
- OVH, cPanel, Plesk and VPS hosting
- WordPress speed and security optimization
RiponTheWebGuy