You wake up to "Error establishing a database connection." You refresh; the site comes back. The host's status page is green. CPU and memory look normal. The database is small. The host suggests upgrading the plan, but the next plan tier costs three times more and you are not convinced it is the cause.
The error returns the next day. And the day after.
This article is the catalogue of real causes for intermittent WooCommerce database connection errors, the diagnostic method I use to find which is yours, and the lasting fix. I have done this rescue many times. The pattern repeats.
The Short Answer
"Error establishing a database connection" almost never has a single cause on a WooCommerce site. There are five real causes, and most fragile sites have two or three at once:
- MySQL
max_connectionsis being saturated. The host configured a low ceiling. Plugins and traffic spikes push past it. - The
wp_optionstable has bloated autoload entries. Every page load reads the autoload set. A 5MB autoload set chokes the database on every request. - A plugin is opening connections without closing them. Connection leaks compound over the day.
- The host throttles MySQL connections silently when it suspects abuse. No alert, no log, just intermittent errors.
wp-cronis running heavy jobs synchronously. Every visitor triggerswp-cronand a queued heavy job runs in their request thread.
Reinstalling the database plugin or rebooting the server clears symptoms briefly. The lasting fix is identifying which causes are present and removing each.
Why The Obvious Fix Fails
"My host says it's fine." The host is checking server-level metrics: CPU, memory, disk, MySQL process count. They cannot see your wp-options autoload bloat, your plugin connection leaks, or your wp-cron queue. They are correct that the server is up. They are not seeing the cause.
"I added a caching plugin." Page caching helps when the cache hits. The errors usually happen on uncached pages: checkout, my-account, cart, admin. Caching does not protect those. It also adds another plugin to the stack, which is its own risk.
"I upgraded the host plan." A bigger MySQL instance has higher max_connections, which masks the symptom for a while. The connection leaks and autoload bloat are still there. The errors return as traffic grows or as the autoload table grows.
"I disabled wp-cron and set up a real cron job." This is a real fix for cause 5. It does not address causes 1, 2, 3, or 4. So the errors return.
"I switched themes." Themes can contribute (poorly-written themes do open connections). They are rarely the dominant cause. Most fragile sites switch theme, lose two weeks to design recovery, and still have intermittent failures because the cause was a plugin.
How I Diagnose This
Step 1: Confirm the error class
What I do. Read the actual error logs (PHP error log, MySQL error log, host-side logs if available). Confirm the error is "Error establishing a database connection" and not "MySQL server has gone away" or "Too many connections" or a plugin-specific failure dressed as a database error. Each class has different causes.
Step 2: Audit the wp_options autoload set
What I do. Run a diagnostic query against wp_options:
SELECT SUM(LENGTH(option_value)) AS total_bytes, COUNT(*) AS option_count FROM wp_options WHERE autoload = 'yes';
Anything above 1MB is suspect. Above 5MB is a near-certain cause. The largest entries are usually orphaned plugin data left behind by uninstalled plugins, or transients that were never expired, or session data that was misconfigured.
Step 3: Identify connection leaks
What I do. Enable MySQL slow query logging if it is not on. Watch the connection count over the day. If the count grows monotonically and only resets when MySQL is restarted, there is a connection leak. If the count is stable but spikes during specific hours, it is a wp-cron issue.
Step 4: Audit the plugin stack
What I do. List active plugins. For each, check the last update date, the WordPress.org review profile, and known issues. Plugins that have not been updated in a year are leak suspects. Plugins that hook into init or wp_loaded and run synchronous database work are autoload-bloat suspects.
Step 5: Check wp-cron behaviour
What I do. Confirm whether DISABLE_WP_CRON is set in wp-config.php. Confirm whether a real cron job is running wp-cron.php. Check the wp_options table for the cron schedule and identify any heavy jobs (typically: WooCommerce action scheduler tasks, plugin batch jobs, or cleanup routines).
Step 6: Confirm host-side throttling
What I do. Compare error frequency against time of day, request volume, and origin IP distribution. Some shared hosts throttle silently when they detect bot traffic. If your error pattern correlates with traffic spikes from a specific origin, this is the cause.
The diagnosis produces a written report ranking causes by likelihood and by impact, plus the fix order.
How I Would Approach The Fix
Phase 1: Stop the bleeding (first 48 hours)
If the site is actively erroring during business hours, the first work is reducing the immediate impact while we investigate.
What I do. Check connection limits. Disable obvious heavy plugins temporarily if they are confirmed leaks. Move wp-cron to a real cron job. Increase MySQL max_connections carefully if the host allows. These are tactical, reversible changes that buy diagnostic time.
Phase 2: Clean the autoload set (week one)
The autoload bloat fix is high-leverage and non-destructive.
What I do. Audit the autoload set. Identify orphaned options from uninstalled plugins. Identify transients that should not be autoloaded. Identify session or cache data that belongs in proper storage. Delete or convert to non-autoload. Watch error frequency drop.
A typical fix moves the autoload set from 5MB to 200KB. Page load times improve as a side effect.
Phase 3: Replace or patch the leaky plugins (week one to two)
Based on the plugin audit, we either update, patch, or replace the plugins responsible for connection leaks. Sometimes this is a simple version upgrade. Sometimes it is a custom patch we maintain. Sometimes it is a replacement.
Phase 4: Optimise wp-cron (week two)
We move heavy scheduled work off the request path. Background jobs run on a real cron, not in visitor threads. Long-running jobs go to Action Scheduler with proper batching.
Phase 5: Configure persistent connections (where appropriate)
On hosts that allow it, MySQL persistent connections plus a tuned connection pool reduce connection churn. Not every host supports this and some plugins misbehave with it. The diagnosis tells us whether it applies.
Phase 6: Monitoring and alerting
We add observability so the next incident is detected before customers complain.
What I build. Application-level error tracking. MySQL connection count graphing. Alerts that fire on connection saturation, autoload bloat growth, and slow query trends.
Phase 7: Documented handover
You keep the cleanup record, the plugin inventory with the "do not install" list, the cron configuration, and the runbook for future incidents.
Honest Variables That Change The Cost Shape
Site age and plugin history. A WooCommerce site that has been live for ten years and has had 60 plugins installed and uninstalled has more autoload bloat than a one-year-old site. The cleanup is bigger.
Host quality. Some hosts give us full MySQL access, some do not. The diagnosis is faster on hosts that allow direct query access.
Traffic level. Low-traffic sites can absorb fixes immediately. High-traffic sites need careful sequencing so the fixes themselves do not cause downtime.
WooCommerce version. Older WooCommerce versions have known bugs that have been fixed. Sometimes the answer is a careful upgrade. Sometimes the upgrade is the fix.
Custom code. Sites with custom plugins or theme code that run database queries in unusual ways are bigger engagements because we have to read that code.
Why I Wrote This
Most articles on "Error establishing a database connection" tell you to call your host. You have. This article exists because the actual causes are diagnosable and the fix is repeatable. If you read this and recognised your symptoms, the technical assessment is the route in. Codeable Certified Expert. Former WooThemes WooWorker. 150 plus WooCommerce projects.