What matters first: WordPress opens database connections through PHP requests. Too many connections can result from traffic, stuck workers, slow queries, bots, a connection leak or several sites sharing one undersized database.
What this symptom actually tells you
A higher max_connections value can postpone the error while increasing memory pressure. The active process list and request concurrency show whether capacity or inefficient work is the true constraint.
Capture evidence before changing anything
- Record the error time and affected sites on the same database host.
- Inspect active and sleeping connections, users, hosts and query duration.
- Compare PHP-FPM worker count with database connection capacity.
- Check slow-query logs, traffic spikes, cron and backup jobs.
Most common causes
- Traffic or bot surge: Many concurrent PHP requests legitimately open connections.
- Slow queries: Connections remain occupied because database work takes too long.
- Oversized PHP pool: More workers can reach the database than it can safely serve.
- Shared-host pressure: Another site or task consumes the common connection budget.
Safe diagnostic and repair sequence
- Reduce or block abusive traffic and pause non-essential batch work.
- Find and optimise the queries holding connections longest.
- Align PHP worker limits, database memory and max_connections as one capacity model.
- Add monitoring for connection use and rejected attempts before returning to normal load.
How to choose between the likely causes
Do not treat Traffic or bot surge and Slow queries as interchangeable. Many concurrent PHP requests legitimately open connections. By contrast, connections remain occupied because database work takes too long. Use two checks to separate them: Record the error time and affected sites on the same database host; and inspect active and sleeping connections, users, hosts and query duration. Those observations usually show whether the next safe move is to reduce or block abusive traffic and pause non-essential batch work or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not repeatedly restart the database as the only fix. It clears evidence and can interrupt writes while the same load immediately rebuilds.
How to verify the repair
- Peak connection use stays below a documented safe threshold.
- Representative uncached requests complete without connection errors.
- Slow queries and abusive traffic are controlled or removed.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
A higher max_connections value can postpone the error while increasing memory pressure. The active process list and request concurrency show whether capacity or inefficient work is the true constraint.
Record the error time and affected sites on the same database host.
Inspect active and sleeping connections, users, hosts and query duration.
Compare PHP-FPM worker count with database connection capacity.
Check slow-query logs, traffic spikes, cron and backup jobs.
What must be verified
- Peak connection use stays below a documented safe threshold.
- Representative uncached requests complete without connection errors.
- Slow queries and abusive traffic are controlled or removed.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Will just raising max_connections solve this permanently?+
Raising max_connections can postpone the error while increasing memory pressure on the database server, without addressing why connections are being consumed. Checking the active process list and query duration reveals whether capacity or inefficient work is the actual constraint.
Is restarting the database a reasonable way to clear this error when it happens?+
No, not as a repeated fix. Restarting clears the evidence needed to diagnose the cause and can interrupt writes, and the same load will often rebuild the same connection pressure immediately afterward. Identify the slow queries or traffic surge behind it instead.
How can I tell if this is caused by real traffic versus a connection leak in my own code?+
Inspecting active and sleeping connections along with their users, hosts, and query duration shows whether many distinct requests are legitimately connecting or whether a smaller number of connections are staying open far longer than expected. A leak typically shows as sleeping connections that don't clear even when traffic is otherwise normal.
If my site is on shared hosting, could another site be the actual cause of my connection errors?+
Yes. On shared hosting, another site or background task can consume the common connection budget for the whole database host, producing this error on a site that isn't itself under unusual load. Recording the error time and affected sites on the same database host helps confirm whether the pressure is shared.