Error Establishing a Database Connection – WordPress Fix

This guide has been written and checked for accuracy but not yet re-verified in a single named environment. The steps are standard and safe; where a step carries risk it is flagged inline.

Quick answer: “Error establishing a database connection” means WordPress cannot reach its database. Either the login details in wp-config.php are wrong, or the database server itself is down or overloaded. Check the four database credentials first — they are the cause after most migrations and host changes. If they are correct, the database server is the problem and your host needs to be involved.

What this error means

WordPress keeps all your content — posts, pages, settings, users — in a MySQL database, separate from the files. On every page load it connects to that database using four credentials stored in wp-config.php. When the connection fails, WordPress has no content to show and prints this error instead of a page.

There are only two broad reasons the connection fails: the credentials are wrong, or the database server is not answering. Working out which one you have takes about two minutes, and it decides everything that follows.

Step 1: Work out which half is broken

Check whether your WordPress admin shows the same error or a different one. Visit yoursite.com/wp-admin. If you see a message mentioning that the database “could not be repaired” or a different database error, WordPress is reaching the server but the database itself has a problem — go to Step 4. If both the front end and admin show the identical connection error, the credentials or the server are the issue — continue with Step 2.

Step 2: Verify the database credentials

This is the cause after most migrations, host moves, or password resets. Open wp-config.php in your site root and find these four lines:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Every one of these must match what your host actually assigned. Log in to your hosting panel, open the MySQL or Databases section, and compare each value:

DB_NAME — the exact database name. After a migration, hosts often prefix it differently (newuser_wp123 instead of olduser_wp123).
DB_USER — the assigned database user, which also changes on migration.
DB_PASSWORD — retype it if unsure, or set a new password for the user in the panel and update it here to match.
DB_HOST — usually localhost, but some hosts require a specific server name like mysql.yourhost.com or an IP. Your host’s documentation states the correct value.

DB_HOST is the one people miss. If the site was working and only broke after moving hosts, and the name, user, and password all look right, localhost is very likely wrong for the new host. Check their docs for the exact database host value before assuming corruption.

Correct any mismatch, save, and reload. If the site returns, that was it.

Step 3: Test whether the database server is up

If the credentials are definitely correct and it still fails, the database server may be down or refusing connections — often because it ran out of memory or hit its connection limit under load. You cannot usually fix this yourself, but you can confirm it before contacting your host.

Most hosting panels include a database tool like phpMyAdmin. Open it. If phpMyAdmin also cannot connect, or shows the database server as unreachable, the problem is server-side and confirmed — contact your host with that detail. If phpMyAdmin connects fine and shows your tables, the server is up and the issue is back to credentials or a WordPress-side problem.

Step 4: Repair a corrupted database

If the admin hinted the database itself is damaged — which can happen after a crash or an interrupted update — WordPress has a built-in repair mode. Add this line to wp-config.php above the “stop editing” line:

define( 'WP_ALLOW_REPAIR', true );

Then visit yoursite.com/wp-admin/maint/repair.php and run the repair. It attempts to fix corrupted tables.

Remove that line the moment you are done. The repair page is accessible without logging in while the constant is set, so leaving it in place is a security hole. Delete the line and save as soon as the repair finishes.

When it still will not connect

Everything checks out but it is intermittent. An error that comes and goes usually means the database server is overloaded — too many connections, or not enough memory on a busy shared server. This is a hosting capacity problem; your host needs to address it, and it is often a sign to move to a plan with more headroom.
It happened right after you edited wp-config.php. A typo — a missing quote or semicolon — breaks the file. Restore your backup copy, or re-check that each of the four lines is exactly as shown.
You genuinely cannot find the right credentials. Ask your host to confirm the database name, user, and host value for your account. They can see all three.

Rollback

The only changes here are to wp-config.php. If you added the repair constant, remove it. If an edit caused a new problem, restore the backup copy of wp-config.php you should have made before starting. None of these steps touch your content.

Frequently asked questions

Will I lose my posts and pages?

Not from these steps. This error is a connection problem, not data loss — your content is still in the database, WordPress just could not reach it. Verifying credentials and running the repair tool do not delete content. Keep a backup anyway, as always.

Why did this start on its own with no changes?

An error that appears without you changing anything is usually the database server, not your site — it crashed, ran out of memory, or hit a connection limit under traffic. If it clears by itself and comes back, that is a strong sign your hosting plan is undersized for your traffic.

Is this the same as the critical error message?

No. The critical error message is a PHP fatal error in code. This is specifically WordPress being unable to reach its database — a different layer, with different causes and fixes.