Fix the database connection timeout by increasing the max_execution_time in PHP and verifying network latency between your web server and database host. This error typically means the script gave up waiting for MySQL or MariaDB to respond. Check server load first, then adjust timeout values.
The error usually appears when PHP hits a hard limit while waiting for the database to acknowledge a query. If your server is slow, this happens often.
In support tickets I handled, the usual culprit was a full disk or a runaway query locking the table. The database isn’t dead; it’s just stuck. The web server, impatient, cuts the line.
You need to distinguish between network issues and application timeouts. A ping to your database IP tells you a lot. If packet loss is high, the link is the problem. If ping is instant but the query hangs, the database is under stress.
Start small. Do not set these to infinite. Bad habits here cause cascading failures later.
Look for max_execution_time and default_socket_timeout in your php.ini or .htaccess file. For most hosting setups, a max_execution_time of 60 seconds is standard. default_socket_timeout should be 30 seconds.
If you are running large imports or complex reports, you might need to bump max_execution_time to 120 or 180. But only for the specific script causing issues. Add it via set_time_limit(120); at the top of the file. Global changes affect every page on your site. That is risky.
Also check the database-side timeout: wait_timeout. This sets how long the MySQL server keeps an idle connection open. If PHP opens a connection, sits idle for 10 minutes, and then tries to reuse it, MySQL may have already killed it. Set wait_timeout to 600 seconds or higher.
Server location matters. If your web host is in Frankfurt and your database is in Singapore, you are fighting physics.
Measure the latency. Run ping database-ip from your terminal. Anything over 50ms for local queries is suspicious. For remote databases, 200ms is acceptable, but 500ms will cause timeouts under load.
Check for CPU spikes too. High load averages (>1.0 per core) mean processes are waiting for CPU time. Your database query might be ready, but the server can’t process it. Use top or your hosting panel’s graph. If CPU is at 100%, adding more timeout time won’t help. You need more resources or better code.
Locked queries prevent others from running. On Linux, run mysqladmin processlist or use your hosting phpMyAdmin.
Look for queries in state: “Locked” or “Sending data”. If a query has been running for minutes, it is likely the blocker. Kill it using KILL [id] in the command line. Then investigate why it exists. Usually, it’s a missing index or a plugin running a heavy query on page load.
When your site gets traffic surges, PHP-Pool processes pile up. Each opens a DB connection. If MySQL’s max_connections limit is hit, new requests queue up.
By default, many shared hosts set max_connections to 50 or 100. If you have 200 PHP processes trying to connect, 100 of them will timeout waiting for a slot to open.
Check your current usage with SHOW STATUS LIKE 'Threads_connected';. If the number is close to max_connections, increase the limit. On VPS, bump it to 150 or 200. On shared hosting, you likely can’t change this. You need to reduce PHP worker count via SUEX or LiteSpeed settings.
If you are using MySQL over remote hosting, firewall rules could silently drop packets. iptables or cloud security groups might block port 3306.
Test connectivity from the web server command line:
telnet database-ip 3306
If it hangs, the port is blocked or filtered. If it connects instantly, the network path is fine.
Also, check if your database is behind a load balancer. Some LBs have their own idle timeouts. If the LB drops the connection after 60 seconds of inactivity, but your app expects it open for 10 minutes, you get a timeout. Configure keepalive intervals in your database connection string to match the LB settings.
WordPress doesn’t define a specific DB timeout. It inherits PHP’s default_socket_timeout, which is typically 30 seconds. If a query runs longer than that, PHP throws the error. You can override this by adjusting PHP settings, but it’s better to fix slow queries instead.
No. It only helps if the database is slow but working. If the network is down, the server is crashed, or the connection limit is hit, increasing time limits does nothing. In fact, it masks the real problem and wastes server resources on stuck processes.
Check the MySQL error log. If you see many “Too many connections” or “Aborted connections” messages, it’s a database-side issue. If MySQL logs look clean but PHP throws timeout errors, the problem is likely in the application layer or network latency.
Absolutely. Plugins that run uncached database queries on every page load can slowly degrade performance. As traffic rises, these queries execute concurrently, filling up connection slots. Deactivate plugins one by one to isolate the culprit. Caching plugins often reduce this risk by serving cached pages.
Never. Setting it to 0 means no limit. If a buggy plugin or query enters an infinite loop, your PHP worker hangs forever. This exhausts your server resources and brings down your entire site. Always set a finite limit, even if it’s high.