One message, three unrelated causes
Error Establishing a Database Connection in WordPress
Diagnose which of three faults is behind Error establishing a database connection in WordPress: the wrong credentials in wp-config.php, a damaged table set, or a database server that has run out of connections. One message, three unrelated fixes. Answer the symptom questions below and the cause table narrows it to one before you change a single file.
Error establishing a database connection means WordPress reached the server and could not open the database. The causes are wrong credentials in wp-config.php, a database server that is down or out of connections, or corrupted tables. Which one it is decides the fix entirely.
Is this what you are seeing?
Tick everything that matches. The result names the cause to start with.
Tick a symptom to narrow it down.
What actually causes it
| Cause | How to confirm | Typical fix |
|---|---|---|
| Wrong credentials | Compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php against the hosting control panel | 5 min |
| Database server unreachable | The host status page, or a direct connection attempt from the command line | 15 min |
| Connection limit reached | Errors cluster at traffic peaks and resolve without intervention | 30 min |
| Corrupted tables | Add WP_ALLOW_REPAIR to wp-config.php and load /wp-admin/maint/repair.php | 20 min |
One message, three unrelated problems
WordPress prints the same sentence whatever went wrong underneath, which is why this error takes so long to fix relative to how simple each cause is.
Wrong credentials is a five-minute fix in a text file. A database server that is down is not your problem to fix at all. A connection limit is a caching problem wearing a database costume. Corrupted tables need a repair or a restore.
Working them in the wrong order is how an afternoon disappears. The symptom checker above exists to pick the order for you.
The tell that separates them
Everything is down, including wp-admin. The server is unreachable or the credentials are wrong. Test them in phpMyAdmin: working there points at the file, failing there points at the server.
The front end works and wp-admin does not. That asymmetry is characteristic of table corruption, because admin screens query tables the front end never touches.
It comes and goes with traffic. A connection limit. Nothing is broken and nothing needs repairing — the site is asking for more connections than the plan allows, and caching is the answer.
Why it recurs
A credentials failure right after a migration or a password rotation is self-explanatory and will not repeat once corrected.
Corruption on a site nobody changed is different. It points at an unclean shutdown, disk trouble, or a plugin writing badly under load, and repairing the table addresses the symptom rather than the cause. Where it happens twice, the hosting is the thing to examine.
Where the database is remote, the connection fails on transport rather than credentials, and that is an SSL cipher mismatch rather than a wrong password. Where PHP dies before it connects at all, the visitor gets a 500 internal server error. Both are on the WordPress error index.
How to fix it
- Copy the database before touching anything. Repair and restore both write to it, and neither is reversible. Where the site is down this feels like a delay; it is the step that keeps a bad outcome from becoming a permanent one.
- Check the host status page. A shared database server under maintenance produces this exact message on every site it hosts, and no amount of work on your install will change it.
- Read the four constants in wp-config.php. DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. Compare each against the control panel character by character. DB_HOST is
localhoston most hosts and something else entirely on managed platforms. - Test the credentials independently. Log into phpMyAdmin or Adminer with the same values. Success there and failure in WordPress means the problem is in the file, not in the server.
- Check whether the connection limit is the cause. Errors that appear under load and disappear afterwards are a limit, not a fault. The fix is a persistent object cache and a page cache, not a change to wp-config.php.
- Run the repair tool if wp-admin alone is broken. Add
define('WP_ALLOW_REPAIR', true);to wp-config.php, load /wp-admin/maint/repair.php, run repair, then remove the constant. Leaving it in place exposes the tool publicly. - Restore from a backup when repair fails. Corruption beyond the repair tool's reach needs the last clean copy, which is why the first step exists.
- Find out why it happened. A credentials failure after a migration is expected. A corruption event on a stable site points at disk problems or a hard shutdown, and it will recur.
When that fix does not hold
Never run the repair tool or a restore before copying the current database. Repair rewrites tables in place and a restore overwrites them, so a database that was recoverable by an expert stops being recoverable by anyone. On a site taking orders, the rows written since the last backup exist only in that copy.
Questions people ask before calling
Why does the error appear suddenly on a site nobody touched?
Almost always the host: a database server restarted, a shared instance hit its connection ceiling, or the account exceeded a resource limit. Check the status page before assuming the site changed, because it usually did not.
Where is wp-config.php?
In the WordPress root, beside wp-admin and wp-content. Some hosts move it one directory above the web root for security, so check the parent directory when it is not where you expect.
What is DB_HOST supposed to be?
localhost on most shared hosting. Managed and cloud platforms frequently use a separate hostname and sometimes a port, and copying a wp-config.php between hosts without changing it produces this error immediately.
The repair tool says the tables are fine. Now what?
Then the tables are fine, and the cause is credentials or the server. Work back through the cause table — a clean repair result is a useful finding, not a dead end.
Can this be prevented?
The credential and corruption causes, largely: keep wp-config.php under version control, and take backups often enough that a corrupt table costs minutes. Host-side limits are prevented by caching, which keeps traffic from reaching the database at all.
More errors