"MySQL server has gone away" almost always means one of three things: the connection sat idle longer than the server's timeout, a query or import tried to send more data than max_allowed_packet permits, or the database hit its connection limit and started refusing new ones. Check the query or script that triggered it first: if it's a large import or a query with big BLOB/TEXT data, it's a packet size problem. If it happens after your site sits idle then gets a hit, it's a timeout problem. If it happens under traffic spikes, it's a connection limit problem.
Read the error first
The exact wording tells you which of the three you're dealing with. MySQL/MariaDB logs connection and query errors, and your application layer usually logs them too. For a WordPress site, check /wp-content/debug.log if WP_DEBUG_LOG is on, or your PHP error log. See Enabling error logging for where each log lives and how to turn logging on if it's off.
- "MySQL server has gone away" mid-query, especially during an import or a query with large data - packet size or timeout.
- "Too many connections" - the account or server connection limit is maxed out.
- "Can't connect to MySQL server" - the database process isn't reachable at all, which is a different problem; see Fixing WordPress database connection errors.
Packet size
max_allowed_packet caps how much data a single query or row can send in one go. Large INSERT statements, big serialized WordPress option values, or importing a dump with wide rows can exceed it. If you're restoring a database dump, import it in smaller chunks or with a client that respects the packet limit (mysql CLI via SSH, or phpMyAdmin's chunked import) rather than pasting one giant SQL file into a web form. If you manage your own MySQL configuration and can raise this value, do it conservatively - a value that's too high just lets a runaway query consume more memory before it fails some other way.
Timeouts
MySQL closes idle connections after wait_timeout (and interactive_timeout for interactive sessions) seconds. Long-running scripts, cron jobs that pause between queries, or a persistent connection your application reuses across requests can all outlive the timeout and get dropped, so the next query on that connection fails with "gone away." The fix is usually application-side: reconnect on failure instead of assuming the connection is still open, or avoid holding a connection open between unrelated operations. In WordPress and most PHP frameworks, the database layer already reconnects automatically on a fresh page load - the problem shows up in long-running scripts, custom cron jobs, or CLI tools that open one connection and hold it.
Connection limits
Every MySQL server and every hosting account has a cap on simultaneous connections. Exact limits vary by plan, and we don't publish a single number here because it depends on what you're on - open a ticket if you need to know yours. What causes you to hit the limit, regardless of the specific number:
- Traffic spikes - more concurrent visitors than usual, each opening a connection.
- Connection leaks - code (often a plugin) that opens a database connection and never closes it, or opens a new one per request instead of reusing the pool. Over time these pile up until nothing new can connect.
- Long-running queries - a slow query holds its connection open longer, so it's still occupying a slot when the next request needs one.
To find a leaking plugin on WordPress: deactivate plugins one at a time (staging site if you have one) and watch whether connection errors stop. Plugins that do a lot of external API calls, background syncs, or their own custom database queries outside WordPress's normal $wpdb object are the usual suspects. Poorly written caching plugins and anything that opens a raw mysqli or PDO connection instead of using the framework's connection handling are common offenders.
If you're on WordPress and a database error is producing a broader failure like a blank page or 500 rather than a clean error message, cross-check against Fixing a 500 Internal Server Error - exhausted resources show up there too, and the fix (raising limits, finding the offending script) overlaps.
Reducing connection pressure
- Use persistent connections carefully - they reduce per-request overhead but hold a slot open longer.
- Add or tune a caching layer (page cache or object cache) so repeat requests don't hit the database at all.
- Batch operations that currently open many short-lived connections into fewer, longer ones, or vice versa if one process is hogging a connection during slow queries.
- Rule out malware or a compromised script hammering the database - if you haven't already, run a scan; see Scanning your website for malware.
When to open a ticket
Contact support if you've confirmed it's not a script or plugin issue on your end, if you need to know your account's actual connection limit before deciding whether to optimize or upgrade, or if the errors are happening account-wide with no clear trigger. Open a ticket from Support → New ticket in the portal, or use live chat. Include the exact error text, when it started, and what you've already ruled out - that saves a round trip.