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

“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

Access to wp-config.php on the server, and the correct database credentials (from your host's control panel or your own records).
WP-CLI, or a database client such as the mariadb/mysql command line, to test the login directly.
A backup of wp-config.php before editing it. One wrong character in that file breaks the whole site, as this guide demonstrates.

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.

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' );

4. 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>

Step	Homepage status
Healthy site	HTTP 200
Wrong password in `wp-config.php`	HTTP 500 — “Error establishing a database connection”
Correct password restored	HTTP 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 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.

Summary

“Error establishing a database connection” is WordPress failing to log into its database. Test the login directly: if the server answers and the right password works while the configured password gets error 1045, the credentials in wp-config.php are wrong — fix the database name, username, password, or host, whichever is off. Verify with wp db check and a homepage load that returns HTTP 200. If the server does not answer at all, or the credentials are right and it still fails, the problem is on the hosting side.

Sources

Common WordPress errors — WordPress.org — “Error establishing a database connection” is usually an error in wp-config.php: database name, username, password, host; then hosting issues (quota, server down) and a possible compromise.
Debugging in WordPress — Developer.WordPress.org — the debugging constants and where errors are logged.