MySQL and Database Errors
MySQL Too Many Connections
Last reviewed
Direct answer
MySQL or MariaDB refused a new client because the server already hit max_connections (or a per-user cap)—reduce runaway PHP/cron/traffic that opens sessions, wait for idle connections to close, then raise limits only after you know peak usage and available RAM.
When the database connection pool is full, WordPress often surfaces “Error establishing a database connection,” intermittent 500s, or host metrics that mention too many connections. Shared plans and busy WooCommerce sites hit this during traffic spikes, bot floods, or plugins that open a new DB link per request without releasing it. This guide covers how to confirm the limit, free capacity safely, and stop the leak instead of blindly raising the ceiling forever.
Key facts
Verifiable numbers and definitions — each claim links to its source.
- MySQL documents ER_CON_COUNT_ERROR (“Too many connections”) when the server has already accepted max_connections clients and cannot take another. (MySQL — Too Many Connections)
- MariaDB documents that when threads_connected exceeds max_connections, clients can receive a too_many_connections error and recommends reviewing max_used_connections before raising the limit. (MariaDB — Handling Too Many Connections)
- WordPress debugging docs describe capturing fatals and DB-related failures in debug.log so connection-limit incidents can be correlated with PHP requests. (WordPress — Debugging)
What the error means
MySQL and MariaDB accept a finite number of simultaneous client connections controlled mainly by max_connections (and sometimes max_user_connections per account). Each PHP-FPM worker, WP-CLI process, cron job, or admin tool that opens a session counts toward that budget until the connection closes or times out. When the server is saturated, new clients receive ER_CON_COUNT_ERROR (“Too many connections”). WordPress rarely prints that exact SQLSTATE on the front end—it usually fails the bootstrap handshake and shows a database connection error, a blank page, or a host 503. This is a concurrency ceiling, not wrong DB_PASSWORD and not the same as crashed tables. Raising max_connections without fixing sleeping piles, slow queries, or bot traffic only delays the next outage and can push RAM usage into OOM kills.
Common symptoms
- Front end or wp-admin fails with “Error establishing a database connection” during peaks, then recovers minutes later
- MySQL/MariaDB or host error logs show “Too many connections” or ER_CON_COUNT_ERROR
- phpMyAdmin or the host database UI sometimes connects and sometimes refuses during the same outage window
- SHOW PROCESSLIST (or host DB metrics) shows Threads_connected near max_connections with many Sleep rows
- Site worsens under bot floods, flash sales, or overlapping backup/cron jobs
- Neighboring sites on the same MySQL instance fail at the same time on shared or multi-site servers
- After a traffic spike ends, the site returns without any wp-config.php change
Most likely causes
- 01 max_connections or plan-level concurrent DB caps too low for the real peak
- 02 Traffic spike, scrape bots, or login brute force opening many PHP workers that each hold a DB session
- 03 Plugins, object-cache misconfig, or custom code opening extra connections per request without pooling
- 04 Long-running queries and Sleep connections piling up past wait_timeout cleanup
- 05 Overlapping backup, staging sync, WP-CLI, and cron jobs competing with front-end traffic
- 06 max_user_connections set on the WordPress DB user lower than the site’s concurrent need
- 07 Neighboring accounts on a shared MySQL host exhausting the global pool
What changed before the problem started
- Marketing campaign, product launch, or viral traffic that multiplied concurrent PHP workers
- New backup, migration, security scan, or analytics plugin that opens heavy DB sessions
- Host plan change, MySQL upgrade, or lowered account connection limits
- Cron or Action Scheduler backlog after a plugin update
- Bot or brute-force wave hitting wp-login.php, xmlrpc.php, or REST endpoints
- Persistent object cache disabled or misconfigured so every request hits MySQL harder
Troubleshooting steps
- 01
Confirm the log says too many connections
Open the host MySQL/MariaDB error log, PHP error log, or managed-host metrics for the outage window and look for “Too many connections,” ER_CON_COUNT_ERROR, or connection-limit graphs at 100%. If the failure is Access denied or Unknown database, switch to the credential playbook instead. Success signal: you have a timestamped log line or metric proving the pool was saturated.
- 02
Restore service by reducing concurrent load
Temporarily enable maintenance mode or a static holding page if the host offers one, pause nonessential cron/backup plugins via FTP by renaming their folders, and ask the host to clear abusive IPs if login/xmlrpc floods appear in access logs. Do not reboot MySQL repeatedly on shared hosting. Success signal: new page loads succeed and Threads_connected drops below the ceiling.
- 03
Inspect who is holding connections
When you can reach phpMyAdmin, Adminer, or SSH mysql, run SHOW FULL PROCESSLIST (or the host equivalent). Note Sleep vs Query counts, long-running statements, and unfamiliar DB users. Kill only clearly stuck queries your host permits—never kill system threads you do not recognize. Success signal: you can name the top consumers (plugin cron, backup user, flood of web user Sleep rows).
- 04
Align WordPress traffic and cron with reality
Disable or reschedule overlapping backup/security scans during business hours, rate-limit or protect wp-login.php and xmlrpc.php, and purge page cache so recovering nodes are not stampeded. If a cache plugin was opening odd DB patterns, leave it off until the pool is stable. Success signal: connection count stays flat during a normal traffic sample.
- 05
Check per-user and plan caps before raising globals
In cPanel/Plesk/managed UI, note max_user_connections for the WordPress DB user and any “concurrent MySQL connections” plan metric. Shared hosts often refuse global max_connections changes—you may need a plan upgrade or a quieter plugin stack instead. Success signal: you know whether the blocker is account quota vs server max_connections.
- 06
Raise limits only with measured headroom
On VPS/dedicated you control, increase max_connections modestly (for example +20–50% above Max_used_connections) after confirming RAM headroom. Restart or reload MySQL per host docs, then retest under monitoring. Success signal: Max_used_connections stays under the new ceiling during a realistic load test without memory alarms.
When to stop troubleshooting
Escalate if you cannot see processlists or logs, the host refuses limit changes while Max_used_connections pegs the ceiling every hour, killing queries feels unsafe, disk/InnoDB errors appear alongside the saturation, or checkout stays down during peak sales. Bring Threads_connected / Max_used_connections samples, the exact too-many-connections log line, and a list of backup/security plugins.
Information to collect before requesting help
- 01 Exact log text (Too many connections / ER_CON_COUNT_ERROR) with timestamps
- 02 Hosting provider, plan type, and whether MySQL is shared or dedicated
- 03 Whether failures are intermittent with traffic or constant
- 04 max_connections / max_user_connections values if visible in panel or SHOW VARIABLES
- 05 Recent traffic spikes, bot attacks, or new backup/cron plugins
- 06 Screenshot or export of PROCESSLIST during the incident (redact private data)
- 07 Age and type of latest database backup before any kill/repair work
How a professional repairs the problem
We prove the outage is connection saturation (not bad credentials), reduce concurrent load from cron/bots/plugins, and identify who holds Sleep and long Query sessions. We restore WordPress bootstrap, then set a sustainable ceiling—plan upgrade, modest max_connections change on servers you control, or plugin/cron redesign—so the next campaign does not recreate the pile-up. You get a short root-cause note with peak connection numbers and what to monitor.
Frequently asked questions
Is this the same as “Error establishing a database connection”? +
Will raising max_connections fix it permanently? +
Can a plugin alone cause this? +
Why does phpMyAdmin fail too? +
Does Cloudflare cause too many connections? +
Should I restart MySQL every time? +
Repair dispatch
Still Need Help Fixing Your Website?
If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.
- You will receive a clear explanation of the likely cause.
- We will tell you if the issue falls outside our repair scope.
- No additional work will be performed without approval.
- A backup should be created whenever access and website condition allow it.
Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.