Error Establishing a Database Connection: Fix It and Stop It Coming Back

"Error establishing a database connection" is WordPress's bluntest failure: white page, one sentence, and the entire site gone, posts, pages, WooCommerce orders, even wp-admin. The good news is that the message is precise. WordPress is running, but it cannot talk to its MySQL database, and there are only about five reasons why. This guide works through them in order of likelihood, then covers how to stop the error recurring, because this is one of the most repeat-prone failures in hosting.

First, scope it

• Check the front end and wp-admin separately. If the front end shows the error but /wp-admin shows "One or more database tables are unavailable", you likely have a corrupted database rather than a connection failure; skip to the repair step.
• Confirm it is down for everyone, not just your connection, with an external check like our free is it down tool.
• Ask what changed in the last hour. A migration, a password change, a plugin install, a traffic spike? The answer usually points straight at the cause.

Cause 1: wrong database credentials

The most common cause, especially right after a migration or a hosting-panel password change. WordPress connects using four values in wp-config.php:

define( 'DB_NAME',     'database_name' );
define( 'DB_USER',     'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST',     'localhost' );

Verify each against the actual database in your hosting panel. Two classics: the password was rotated in the panel but not in the file, and DB_HOST is wrong for the new host, some hosts use localhost, others need a specific hostname or a port. You can prove the credentials outside WordPress by connecting with them directly (phpMyAdmin login, or mysql -u user -p on the command line). If they fail there, the problem is the credentials, not WordPress.

Cause 2: the database server is down

If the credentials are right, the MySQL service itself may have stopped, crashed by the host, killed by the out-of-memory manager, or down for maintenance. On managed hosting, check the host's status page and open a ticket. With server access, check and restart the service:

systemctl status mysql     # or mariadb
sudo systemctl restart mysql

If MySQL restarts and then dies again within minutes, look at why it is crashing (usually memory, see cause 3) rather than restarting it in a loop.

Cause 3: exhausted resources

The intermittent version of this error, working one minute, broken the next, is almost always resource exhaustion: MySQL hitting max_connections because a traffic spike (or an aggressive crawler, or a badly written plugin query) opened more connections than the server allows, or the server running out of memory and the OS killing MySQL to survive. This is the classic failure of a growing site on a small hosting plan. Short term, restarting MySQL clears it. Properly: identify the query or plugin holding connections, add caching so most visits never touch the database, or move up a hosting tier.

Cause 4: a corrupted database

If wp-admin mentioned unavailable tables, add this line to wp-config.php, temporarily:

define( 'WP_ALLOW_REPAIR', true );

Then visit yoursite.com/wp-admin/maint/repair.php and run the repair. Remove the line immediately afterwards, the repair page needs no login, so leaving it enabled is an open door. Corruption usually follows a crash mid-write or a full disk, so check both.

Cause 5: compromise

Less common but real: malware that modified wp-config.php, a deleted database user, or a ransacked database. If credentials look changed and nobody on your team changed them, treat it as a security incident, our guide on telling whether your site has been hacked covers the full response, and reach for backups.

Stopping the repeat

This error has a shameful secret: most sites that show it have shown it before. It disappears on a restart, everyone moves on, and it returns under the next traffic spike. Prevention is boring and effective:

• Monitoring that catches it in a minute. The error usually returns an HTTP 500, which uptime monitoring sees instantly, but caching layers can serve the error page with a healthy 200 status. A content rule that alerts if any page ever contains the phrase "error establishing a database connection" catches it regardless of status code, which is exactly the kind of belt-and-braces check content monitoring exists for.
• Right-size the hosting. If the error correlates with traffic, the fix is capacity or caching, not restarts.
• Backups you have actually tested, because cause 4 and cause 5 both end at "restore".
• Keep an eye on the whole WordPress stack. Database errors are one of several WordPress-specific failure modes worth watching; our WordPress monitoring guide covers the full set.

For agencies, multiply by every client site on shared hosting and this error is a when, not an if. The difference between a non-event and an angry phone call is whether your monitoring or their customer found it first.