Fix "Error Establishing a Database Connection" in WordPress

You open your site and instead of your homepage, there's one blunt line of white-on-grey text: Error establishing a database connection. No stack trace, no hint about which plugin or theme is at fault — WordPress just refuses to talk to MySQL and stops there. The good news is that this exact error only has a handful of real causes, and you can usually tell which one you're dealing with in under five minutes.

Symptom: What You'll See (and What It Rules Out)

This error shows up in a few slightly different places, and where you see it first is a clue:

• Front-end and wp-admin both down, showing the same plain error — usually a credentials, host, or MySQL service problem.
• Front-end works, wp-admin says "One or more database tables are unavailable" instead — that's a different problem (table corruption), not a connection failure. We cover that one in a separate guide.
• The error is intermittent, tied to traffic spikes — that points to a connection limit issue, not a broken connection. If that's your pattern, our max_connections troubleshooting guide is the better fit.
• Error appears right after a migration, restore, or server move — this is the most common trigger for the true "can't connect at all" version of this error, and it's what this guide focuses on.

Cause: The Four Things That Actually Break This

Strip away the noise and "Error establishing a database connection" almost always comes down to one of these:

1. Wrong credentials in wp-config.php — the DB name, username, or password no longer matches what MySQL has on record. Common after a manual migration where the database was recreated with a new password.
2. Wrong DB_HOST value — the site was moved to a server where MySQL doesn't listen on localhost, or it's on a different host/socket entirely (common with some managed setups and remote database servers).
3. MySQL/MariaDB isn't running — the service crashed, hit an out-of-memory kill, or didn't come back up after a reboot.
4. The database itself is missing or renamed — happens if a restore only brought back files and not the database, or someone renamed/dropped it during cleanup.

Work through these in order — each one takes thirty seconds to check and rules out an entire category of causes.

Fix: Step-by-Step Diagnosis

1. Confirm MySQL Is Actually Running

SSH in and check the service first, since nothing else matters if the database daemon is down:

systemctl status mysqld
# or, depending on the OS/panel:
systemctl status mariadb

If it's stopped, start it and immediately check the error log for why it died:

systemctl start mysqld
tail -50 /var/log/mysqld.log

A crash loop here is usually memory pressure (MySQL got OOM-killed) or a corrupted InnoDB log file after an unclean shutdown. If it won't stay up, that's a separate investigation — but at least you've confirmed the connection error is a symptom, not the disease.

2. Verify the Credentials in wp-config.php

Open wp-config.php in File Manager or via SSH and check these four lines:

define( 'DB_NAME', 'yourdb_name' );
define( 'DB_USER', 'yourdb_user' );
define( 'DB_PASSWORD', 'yourdb_password' );
define( 'DB_HOST', 'localhost' );

Then test those exact credentials directly against MySQL, bypassing WordPress entirely:

mysql -u yourdb_user -p yourdb_name -h localhost

If that command itself fails with Access denied, the password in wp-config.php doesn't match what MySQL has — WordPress isn't lying to you. Reset the DB user's password in cPanel > MySQL Databases, then update DB_PASSWORD to match. If the command works fine but the site still errors, the problem isn't credentials — move to the next step.

3. Check DB_HOST — "localhost" Isn't Always Right

On most cPanel shared hosting, localhost is correct because MySQL runs on the same box. But if you've migrated to a setup with a separate database server, or you're on certain managed cloud stacks, MySQL might live on a different host or a non-default socket path. Ask your host (or check your welcome email) for the actual DB host value, and confirm the port if MySQL isn't on the default 3306.

4. Confirm the Database Actually Exists

Log into phpMyAdmin or run:

mysql -u root -p -e "SHOW DATABASES;"

and look for your site's database in the list. If it's not there — if a restore only copied the WordPress files and skipped the SQL import, or someone dropped the database during a cleanup — you'll need to import a database backup and recreate the DB user with matching privileges before the site will connect again.

5. Rule Out a Corrupted wp-config.php

Occasionally the file itself is the problem — a bad find-and-replace, a botched manual edit, or an incomplete file transfer leaves stray characters or a missing closing PHP tag. Compare it against a known-good backup copy, or regenerate it by re-running the five-minute WordPress install against the existing database (it won't touch your content, just the config file).

If all four checks pass and the error still shows up only under load rather than constantly, you're actually dealing with a connection-limit problem, not a broken connection. Don't keep chasing credentials at that point — check max_connections and your active connection count instead.

Prevention: Stop This From Happening Again

Frequently Asked Questions

Does this mean my WordPress data is lost?

Almost never. This error means WordPress can't reach the database — it says nothing about whether the data inside that database is intact. Once the connection is restored (correct credentials, running MySQL service, correct host), your posts, pages, and settings are exactly where you left them.

I checked everything above and it's still broken. What's next?

Check the MySQL user's host permissions — the user needs to be granted access from the host WordPress is connecting from (usually localhost). In cPanel, go to MySQL Databases and confirm the user is actually assigned to that database with all privileges, not just created.

Can a plugin or theme cause this error?

Directly, no — this specific error happens before WordPress loads plugins or themes, at the initial database handshake. If disabling plugins "fixes" it, you were likely looking at a different error (like a fatal PHP error) that just resembled this one.

Why did this start right after I moved to SkyServer?

Migrations are the single most common trigger. The database export/import step or the DB user/password pairing is the part most likely to get missed or mismatched during a manual move — double-check that the imported database name and the user's password both match exactly what's in the new wp-config.php.

Is there a way to see the real MySQL error instead of the generic message?

Yes — temporarily add define( 'WP_DEBUG', true ); to wp-config.php and reload. WordPress will often show the underlying MySQL error text (access denied, unknown host, etc.) instead of the generic message, which tells you exactly which of the four causes above you're facing. Turn it back off once you're done, since debug mode shouldn't stay on for a live site.