Skip to content

SiteRepairManual

WordPress repairs run on a throwaway install before they are written down.

Fix “Error establishing a database connection”

Checked 9 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 5 minutes

Case file

Symptom
“Error establishing a database connection”, with HTTP 500
Cause
The database password in the WordPress configuration file is wrong
Fix
Test the login directly, then correct the password
Result
The database check passes and the homepage returns HTTP 200

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

“Error establishing a database connection” means WordPress cannot reach its database. The message itself does not say why, and the two common reasons need opposite fixes: wrong credentials in wp-config.php, which you can fix yourself, or a database server that is down or over quota, which is your host's job. The official common-errors guide lists the credentials first — database name, username, password, and host — and then the hosting issues. This guide reproduces the credentials case, shows how to prove it is the credentials, and fixes it.

What you need

The diagnosis

1. Confirm the symptom

In the reproduction, the healthy site returned HTTP 200. After the database password in wp-config.php was changed to a wrong value, the homepage returned:

Output — homepage with the wrong database password

HTTP 500, 2482 bytes
Error establishing a database connection

Key result: HTTP 500 with the exact text “Error establishing a database connection”. WordPress reached the web server fine — it is the database leg that failed. The next step is to find out which side of that leg is at fault.

2. Work out whether it is the credentials or the server

Test the database login directly, bypassing WordPress. First the credentials WordPress is supposed to use, then a deliberately wrong password for comparison. In the reproduction the database user was wpuser on localhost:

Command — test the login with the correct password

mariadb -u wpuser -pwppass123 -e "SELECT 1 AS server_and_right_password_ok;" wp_test

Output

server_and_right_password_ok
1

Command — test the login with the wrong password

mariadb -u wpuser -pwrongpassword -e "SELECT 1;" wp_test

Output

ERROR 1045 (28000): Access denied for user 'wpuser'@'localhost' (using password: YES)

The server answers, and the right password works — so the server is up and the account exists. The wrong password is refused with error 1045. That combination points at the credentials in wp-config.php, not at the server. wp db check said the same thing from the WordPress side:

Output — wp db check with the wrong password

mariadb-check: Got error: 1045: Access denied for user 'wpuser'@'localhost'
(using password: YES) when trying to connect

Key result: error 1045 “Access denied” with a server that answers means the credentials are wrong. If the login test had failed to connect at all — connection refused, or a timeout — that would point at the server being down, and the fix would be with the host.

Trap: check all four values in wp-config.php, not just the password. The official guide lists database name, username, password, and host. A password that is right for the wrong database name, or a host that changed during a migration, fails with the same message.

The fix

3. Fix the credentials in wp-config.php

Open wp-config.php and correct the value that is wrong. In the reproduction only the password was wrong, so the fix was one line. With WP-CLI:

Command — restore the correct password

wp config set DB_PASSWORD wppass123

Output

Success: Updated the constant 'DB_PASSWORD' in the 'wp-config.php' file
with the value 'wppass123'.

If you edit the file by hand, the line looks like this — keep the quotes and the semicolon exactly as shown:

Config — the corrected line in wp-config.php

define( 'DB_PASSWORD', 'wppass123' );

Verify the site is back

Check the database from the WordPress side first, then the homepage:

Command — check the database through WP-CLI

wp db check

Output

Success: Database checked.

Output — homepage after the fix

HTTP 200
<title>SRM Test</title>
StepHomepage status
Healthy siteHTTP 200
Wrong password in wp-config.phpHTTP 500 — “Error establishing a database connection”
Correct password restoredHTTP 200

Trap: if you test with the PHP built-in server, give it a few seconds after editing wp-config.php before judging the result. Its OPcache holds the compiled file for up to opcache.revalidate_freq (2 seconds by default), so a check run inside that window can show the previous state — this reproduction saw a stale HTTP 200 right after breaking the password, and a stale HTTP 500 right after fixing it, both corrected on the next check. On normal hosting (PHP-FPM or mod_php) the file is read fresh per request and this does not apply.

If that didn’t work

If the credentials are right and the error stays, the official guide's next steps apply: the database may have hit its quota, or the server may be down — both are hosting issues, so contact the host. And if the credentials were right all along, consider the guide's last possibility: a compromised site can produce the same error, in which case a malware scan is the next step.

What happened

The site could not reach its database because the password in wp-config.php was wrong. A direct login test showed the server answering and the right password working, so the password was corrected in wp-config.php, the database check passed, and the homepage returned HTTP 200.

Where this came from