Error Establishing a Database Connection in WordPress: How to Fix It

You load your site and every page — front end and wp-admin alike — is replaced by a single grey sentence: Error establishing a database connection. Nothing renders, because nothing can. WordPress never got as far as building a page.

Here is the mental model that makes this quick to fix. WordPress keeps all your content — posts, pages, settings, users — in a MySQL database, not in files. On every request it reads four login details from wp-config.php, connects to that database, and pulls what it needs. This error means that connection was attempted and refused. The fix is to work out why it was refused, and there are only three possibilities.

The three causes, in order of likelihood

1. A wrong credential in wp-config.php — the usual result of moving hosts.
2. The database server is down or overloaded — the usual result of nothing changing on your side.
3. The database is corrupted — less common, and it announces itself differently.

Work through them in that order.

Step 1: check the four credentials

Open wp-config.php in the root of your site over SFTP or your host’s file manager. Four lines define the connection:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Every one of these must match exactly what your host assigned. Open your hosting control panel’s database section (in cPanel it is “MySQL Databases”) and compare character for character:

• DB_NAME — hosts often prefix the name with your account, like cpaneluser_wpdb. The prefix is part of the name.
• DB_USER — same prefixing applies, and the user must be assigned to that database, not just exist.
• DB_PASSWORD — the single most common culprit. If you are unsure, reset it in the control panel and paste the new value in. Watch for a trailing space or a smart quote.
• DB_HOST — do not assume localhost. Many hosts use a dedicated database server with an address like mysql.yourhost.com, sometimes with a :port. The control panel shows the right value.

Because this file is exactly where these four values live, the safest way to regenerate a clean, correctly-quoted wp-config.php is the wp-config.php generator — fill in the four database fields and paste the result over the old block.

This step alone fixes the error after almost every migration, because credentials that were right on the old host are wrong on the new one.

Step 2: confirm the database server is actually up

If the credentials are correct and the error persists — especially if it appeared on its own with no change from you — the database server itself is the suspect.

On shared hosting this is common and usually temporary: the MySQL service gets overwhelmed during a traffic spike or hits its per-account connection limit and starts refusing new connections. It typically recovers within a few minutes. Reload after a short wait before doing anything drastic.

To test whether the credentials are even valid independent of WordPress, drop a tiny script beside wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Use your real DB_HOST, DB_USER and DB_PASSWORD. If it prints Connected, your login details work and the problem is elsewhere (a corrupted database, Step 3). If it prints a connection error, the message tells you which: “Access denied” means a wrong user or password; “Can’t connect to MySQL server” means a wrong host or a genuinely down service — time to contact your host. Delete the script the moment you are done.

Step 3: repair a corrupted database

One tell separates corruption from a connection problem: the front end loads but wp-admin shows the error, or the reverse. If the connection were truly refused, both would be dead. A split like that points at damaged tables.

WordPress has a built-in repair tool. Add one line to wp-config.php, above the “stop editing” comment:

define( 'WP_ALLOW_REPAIR', true );

Then visit this URL directly in your browser:

https://yoursite.com/wp-admin/maint/repair.php

It loads without a login — that is the point, since you may be locked out — and offers “Repair Database” and “Repair and Optimize Database.” Run it.

Then immediately delete that line from wp-config.php. While it is present, anyone on the internet can hit that URL and run a repair on your database. This is not optional cleanup; it is closing a hole you just opened.

Step 4: when repair will not even connect

If the repair page itself shows the connection error, there is nothing to repair — the database cannot be reached at all, so you are back to Step 1 or Step 2. At that point the reliable move is to restore the database from your host’s most recent backup. Most control panels keep automatic daily database snapshots; a restore from last night is almost always faster and safer than chasing a corruption you cannot connect to.

Advice you can safely ignore

“Just reinstall WordPress.” This error is about the database connection, not core files. Reinstalling replaces the very files that are working fine and touches nothing that is broken.

“Increase your PHP memory limit.” Memory exhaustion is a different error with a different message. Raising the limit does nothing for a refused database connection and only hides that you never checked the credentials.

“Clear your cache.” The failure happens in PHP before any cache can serve a page. Clearing the cache changes nothing while the connection is refused; it is only worth doing after the site is back.

“Edit the database directly to fix it.” Reaching for phpMyAdmin to hand-edit tables before you have confirmed the connection even works is how a temporary outage becomes permanent data loss. Confirm the connection first; touch the data last, and only from a backup.

Still stuck?

If the credentials verify with the test script, the server is up, and repair connects and reports no errors, but the site still shows the message, the remaining suspect is a plugin that talks to the database on its own connection — a caching or database plugin that stored a stale host. Rename wp-content/plugins to plugins-off over SFTP to rule it out. If the error clears, reintroduce plugins one at a time until it returns.