Error establishing a database connection
WordPress loaded, read wp-config.php, and could not get an answer from MySQL. Every page on the site is blank until it can.
Error establishing a database connection
Nine times in ten the credentials in wp-config.php no longer match the database. Confirm with a direct connection using exactly those four values; if that connects, the problem is not the credentials and the next section tells you where to look instead.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| Wrong credentials in wp-config.php | Connect by hand with the same four values wp-config.php uses. If that fails with "Access denied", the file is the problem and nothing else needs testing. | Correct DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. A migration is the usual reason they drifted: the archive brought the old host's values with it. |
| The database server is not running | The same direct connection fails with "Can't connect" rather than "Access denied". The distinction between those two messages is the whole diagnosis. | Start MySQL. If it will not stay up, its own error log names the reason, and on shared hosting that reason is usually memory. |
| The database hit its connection limit | The error is intermittent - the site works, then does not, then does. A direct connection succeeds while visitors are still seeing the error. | Raise max_connections, or find what is holding connections open. A plugin opening a connection per request and never closing it is the common culprit. |
| A corrupted table | Only some pages fail, or wp-admin loads while the front end does not. WordPress may offer a repair link instead of this error. | Run a repair. Set WP_ALLOW_REPAIR in wp-config.php, visit /wp-admin/maint/repair.php, then remove the constant - that page has no authentication. |
| DB_HOST names something unreachable | Credentials are right and MySQL is up, but the host in wp-config.php does not resolve from the web server. | Use the hostname the web server can actually reach. On containerised stacks that is a service name, not localhost, and localhost is what most migrated configs contain. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Read what wp-config.php actually says
Not what you remember setting. The four constants that matter are near the top of the file.
grep -E "DB_(NAME|USER|PASSWORD|HOST)" wp-config.php
Try those exact values against MySQL
This is the test that splits the problem in two. "Access denied" means the credentials are wrong; "Can't connect" means the server is not answering.
mysql --user='DB_USER' --password='DB_PASSWORD' --host='DB_HOST' 'DB_NAME' -e 'SELECT 1;'
If credentials were wrong, correct them
Edit wp-config.php, or set them with WP-CLI so you do not have to find the right quotes yourself.
wp config set DB_PASSWORD 'the-real-password' wp db check
If the server was down, look at why before restarting it
A MySQL that died once will die again. Its error log names the reason, and out-of-memory is the most common answer on a small server.
tail -n 50 /var/log/mysql/error.log
Confirm from WordPress, not from the shell
A shell connection proves MySQL is reachable from the shell. Only WordPress can prove it is reachable from WordPress.
wp db check && wp option get siteurl
What the platform takes off the list.
The credentials never drift here, because wp-config.php does not carry them: it reads them from the environment with getenv(), so rotating a password is a change in one place rather than an edit that has to be repeated in a file. The database runs in its own container with its own memory allowance, so a busy PHP process cannot starve it, and Fix Site re-points a restored site at the right database in one action.
Questions, answered.
Why did this start on its own, with nothing changed?
Does this mean my data is gone?
Should I use the built-in repair page?
The site works and then breaks every few minutes. What is that?
If that was not it.
These fail in ways that look similar from the browser.