Error Establishing a Database Connection: Fixed

"Error establishing a database connection" means WordPress could not reach or could not use its database, and there are four causes: wrong credentials, a database server that is down, corrupted tables, or a compromised site.

Work them in that order. Not because the first is most likely, but because checking it costs thirty seconds and the last one changes what you do about everything else.

One warning before you start, because it is the most-recommended fix on the internet and it is handed out without its caveat: WordPress's built-in repair tool can be used by anyone on the internet while it is enabled. More on that below.

---

The four causes

Cause	Typical trigger	How fast it confirms
Wrong credentials	A migration, a host change, a password rotation	Seconds — read wp-config.php
Database server down or overloaded	Host incident, resource limit, traffic spike	A minute — ask the host or check status
Corrupted tables	Unclean shutdown, disk problem, interrupted update	Ten minutes
Compromised site	Injected code, changed credentials, unexpected admin users	Requires a proper look

The signature that separates them: credentials that were working and stopped usually means something changed on the host. A site that alternates between working and erroring usually means the database server is overloaded rather than misconfigured. And an error appearing alongside other oddities — unexpected redirects, unknown admin users — points at compromise.

---

Before anything: back up

Even now, especially now. If the database is corrupt, a copy of the corrupt database is still more useful than nothing, and any repair attempt can make things worse.

Take the files and whatever database export you can get. If you cannot export it, your host almost certainly has a recent backup — ask before you change anything, because some fixes overwrite the thing you would want to restore.

---

The fix, in order

Step 1 — Read the credentials in wp-config.php

Four values, near the top:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'password' );
define( 'DB_HOST', 'localhost' );

Compare each against what your host's control panel shows. WordPress's own guidance names incorrect credentials as the first thing to check, and a migration or host change is the usual reason they stopped matching.

DB_HOST is the one that catches people. It is localhost on most shared hosting and something else entirely on many managed and cloud hosts — a hostname, an IP, sometimes with a port. Copy it from the control panel rather than assuming.

A password containing quotes or backslashes needs escaping. If a rotated password suddenly broke the site, this is a likely reason.

Step 2 — Ask whether the database server is up

If credentials are right, the next question is whether anything is listening.

• Check your host's status page and support channel for an incident
• Check whether other sites on the same account are also down
• Consider resource limits. Shared hosting caps concurrent database connections, and a traffic spike or a runaway plugin query can exhaust them — which produces exactly this error, intermittently

Intermittent is the tell. A site that works, then errors, then works again is almost never a credentials problem. It is capacity.

Step 3 — Check whether the site was compromised

WordPress's documentation names a compromised site as one cause, and it is the one that changes everything else you do.

Signs worth taking seriously: credentials changed that you did not change, admin users you do not recognise, unexpected files in wp-content, or the error appearing alongside redirects to somewhere unfamiliar.

If any of that is present, stop treating this as a database problem. Repairing tables on a compromised site fixes a symptom and leaves the cause running. The triage sequence is in my WordPress site is hacked: a triage plan.

Step 4 — Test the connection independently

Before repairing anything, establish whether the credentials work at all — separately from WordPress.

Log into phpMyAdmin (or your host's database tool) using the same username and password from wp-config.php.

• You get in — credentials are fine, and the problem is the database itself or WordPress's use of it
• You cannot — the credentials are wrong or the user has lost its permissions, which is back to step one

This single check separates "wrong password" from "corrupted database" definitively, and most guides skip it, which is why people run repair tools on databases that were never corrupt.

Step 5 — Repair the tables, carefully

Read this before enabling it.

WordPress includes a repair tool, enabled by adding one line to wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

It is then reachable at yoursite.com/wp-admin/maint/repair.php.

The warning, in WordPress's own words: "This should only be enabled if needed and disabled once the issue is solved. When enabled, a user does not need to be logged in to access the functionality."

Read that again. While that constant is present, anyone who knows the URL can run the repair tool on your database — no login required. That is deliberate, because a corrupt database often prevents logging in. It is also why the line must come out the moment you are finished.

So the sequence is:

1. Add the line
2. Run the repair at /wp-admin/maint/repair.php
3. Remove the line immediately
4. Confirm the site works

The alternative, if you have database access: repair the tables through phpMyAdmin directly — select the tables, choose Repair — which requires no publicly reachable tool at all. WordPress's own error documentation points here too, and it is the safer route whenever you can log into the database.

Step 6 — Escalate with specifics

If credentials are right, the database is up, the tables are clean and the site is not compromised, it is the host's.

Give them: the exact error, the DB_HOST value you are using, confirmation that you can or cannot log into phpMyAdmin with those credentials, and whether the failure is constant or intermittent.

That last detail matters most. Intermittent points at resource limits, which is a different team and a different fix from a dead database server.

---

The special case: it broke after a migration

Migrations produce this error more than anything else, and the causes are predictable.

• DB_HOST still points at the old host. The most common single cause
• The database user was not recreated on the new server, or has no privileges on the database
• The password was set differently from the one in wp-config.php
• The import did not complete, leaving some tables missing rather than corrupt
• Table prefix mismatch — $table_prefix in wp-config.php must match what is actually in the database, and an import into a differently-prefixed set produces confusing failures

Check the prefix. It is the one people forget, and the symptoms look like corruption rather than configuration.

---

Frequently asked questions

What causes "error establishing a database connection" in WordPress?
Four things: incorrect credentials in wp-config.php, a database server that is down or overloaded, corrupted database tables, or a compromised site. Check them in that order — credentials take seconds to verify and a compromise changes how you handle everything else.

How do I fix the WordPress database connection error?
Verify DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php against your host's control panel, then test those same credentials by logging into phpMyAdmin. If they work, the problem is the database or the server rather than the configuration.

Is WP_ALLOW_REPAIR safe to use?
Only briefly. WordPress states that while it is enabled, a user does not need to be logged in to access the repair tool — so anyone who knows the URL can run it. That is intentional, because a corrupt database often prevents logging in, and it is why the line must be removed immediately afterwards.

What is DB_HOST supposed to be?
Usually localhost on shared hosting, but many managed and cloud hosts use a specific hostname, IP address or port. Copy the value from your host's control panel rather than assuming — an outdated DB_HOST is the most common cause of this error after a migration.

Why does the error come and go?
Intermittent failures point at capacity rather than configuration. Shared hosting limits concurrent database connections, and a traffic spike or an inefficient plugin query can exhaust them. Credentials that are wrong fail consistently, not sometimes.

Can a hacked site cause a database connection error?
Yes, and WordPress's own documentation names a compromised site as one of the causes. Changed credentials, unfamiliar admin users or unexpected files alongside the error are the signs. Repairing tables on a compromised site treats a symptom while the cause continues.

How do I repair WordPress database tables?
Either through phpMyAdmin — select the tables and choose Repair — or with WordPress's own tool by adding WP_ALLOW_REPAIR to wp-config.php and visiting /wp-admin/maint/repair.php. The phpMyAdmin route is safer because it requires no publicly reachable page.

Why did this happen right after I moved hosts?
Almost always DB_HOST still pointing at the old server, a database user that was not recreated with the right privileges, or a table prefix in wp-config.php that does not match the imported database. Check the prefix — it is the one people forget and it mimics corruption.

---

What to do next

Open wp-config.php and read the four database constants against your host's control panel. Thirty seconds, and it resolves the most common cause outright.

If they match, try logging into phpMyAdmin with the same username and password. That one test tells you whether you have a credentials problem or a database problem, and it decides everything after it.

---

Related guides

• When WordPress breaks: a diagnostic order — the full symptom map
• My WordPress site is hacked: a triage plan — if compromise is the cause
• Blank page after a WordPress update? Fix it — a different failure entirely
• WordPress backups: what most people get wrong — what makes this survivable
• Locked out of WordPress admin? How to get back in — once the database is reachable again