How to Fix "Error Establishing a Database Connection" in WordPress

The "Error establishing a database connection" message means WordPress can't talk to your MySQL database — and your entire site goes blank for every visitor until it's fixed. The good news: in the majority of cases the cause is one of four things, all of them fixable without touching a line of code you don't understand. Work through the steps below from easiest to riskiest and you'll be back online.

What You're Actually Seeing

WordPress is a two-part system: PHP files on the server, and a MySQL (or MariaDB) database that holds your content, settings, and users. Every page load requires a live connection between the two. When that connection fails, WordPress has nothing to display — so it shows the error instead of your site.

You may see one of two variations:

• Front end: "Error establishing a database connection" on every public page.
• Back end: "One or more database tables are unavailable. The database may need to be repaired." when you try to reach /wp-admin.

Both point to the same underlying problem, though the back-end version often means the database is reachable but corrupted — a slightly different fix path covered below.

The Four Most Likely Causes

1. Wrong database credentials in wp-config.php — the most common cause after a migration, host change, or someone editing the file by hand.
2. The MySQL service is down — the database server crashed or was restarted by your host, often under sudden traffic load or after a server-level update.
3. Corrupt database tables — a bad plugin update, an interrupted write during a crash, or a PHP process that was killed mid-query can leave tables in an inconsistent state.
4. Your host has suspended or locked the database — resource limits, a billing lapse, or a security flag can cause the host to temporarily revoke database access.

Before You Start: Take a Backup

If you have any access at all — cPanel, Plesk, SSH, or your host's dashboard — export a copy of the database before changing anything. A database dump takes two minutes in phpMyAdmin and can save hours of pain if a repair step goes wrong.

Step 1 — Check Your Database Credentials in wp-config.php

Open your site's root folder via FTP, SFTP, or your host's File Manager and find wp-config.php. Look for 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' );

Now compare each value against what your host actually has on record. In cPanel this is under MySQL Databases; in Kinsta, WP Engine, or other managed hosts it's in the hosting dashboard under database settings. Pay close attention to:

• Exact capitalisation of the database name and username — MySQL on Linux is case-sensitive.
• Special characters in the password that may need escaping.
• DB_HOST — most shared hosts use localhost, but some use a remote hostname like mysql.example.com or a port like localhost:3306. Check your host's documentation if localhost isn't working.

Correct any mismatch, save the file, and reload the site. If it comes back, you're done.

Step 2 — Verify the MySQL Service Is Running

If credentials are correct, the database server itself may be down. The quickest test: log in to phpMyAdmin from your hosting panel. If phpMyAdmin won't load or throws its own connection error, MySQL is down at the server level — this is a hosting problem, not a WordPress problem.

What to do:

• Check your host's status page for outage notices.
• Open a support ticket with your host and ask them to confirm MySQL is running and your database user has the correct privileges.
• If you're on a VPS or dedicated server and have SSH access, you can check directly: sudo systemctl status mysql (or mysqld depending on your distro) and restart if needed with sudo systemctl restart mysql.

Step 3 — Repair Corrupt Database Tables

If you can reach phpMyAdmin but the site is still erroring, your tables may be corrupt. WordPress has a built-in repair tool for this, but you have to enable it manually.

Add this line to wp-config.php just before the line that says "That's all, stop editing!":

define( 'WP_ALLOW_REPAIR', true );

Then visit https://yoursite.com/wp-admin/maint/repair.php in your browser. You don't need to be logged in — WordPress will run the repair without authentication when that constant is set. Click Repair and Optimize Database and let it finish.

Important: Remove that line from wp-config.php immediately after the repair. Leaving WP_ALLOW_REPAIR active lets anyone run database operations on your site without a password.

If the built-in repair can't fix all tables, you can run repair queries directly in phpMyAdmin. Select your database, check the damaged tables, and use the With selected → Repair table option from the drop-down.

Step 4 — Check for Host-Side Suspension or Privilege Issues

Some hosts suspend database access automatically when you hit resource limits or when their security scanner flags unusual activity. Signs of this include:

• The error appeared suddenly with no changes on your end.
• phpMyAdmin shows the database exists but the user has no privileges.
• Your hosting dashboard shows a warning or banner about your account.

In phpMyAdmin, click your database username under User accounts and verify that this user has full privileges on your site's database. If privileges were stripped, re-grant them (your host support can do this if you're not comfortable). Then contact support to find out why they were removed in the first place — sometimes it indicates a security event worth investigating. For a deeper look at what a compromised site looks like, see our guide on WordPress site hacked — how to clean it up safely.

Step 5 — Test With a Fresh Database Connection

If you've checked everything above and the error persists, create a brand-new database user in your hosting panel, grant it full permissions on your site's database, update wp-config.php with the new credentials, and test again. This rules out any corruption in the MySQL user account itself — something that's rare but does happen after server migrations.

A Note on wp-config.php DB_HOST Values

Managed WordPress hosts — Kinsta, WP Engine, Flywheel, Cloudways, and others — often use non-standard DB_HOST values. If you recently migrated to one of these hosts and the error appeared right after, the DB_HOST in your wp-config.php is the first thing to verify. Your host's migration documentation or onboarding email will list the correct value. Never guess — one character off and you'll stay broken.

How to Prevent This Error in Future

• Automated daily backups — a reliable backup means a corrupt database is a restore, not a disaster. Store backups off-site (not just on the same server).
• Staging environment for migrations — test credential changes on a staging copy before touching production.
• Uptime monitoring — tools like UptimeRobot alert you within minutes of downtime so you're not the last to know.
• Keep WordPress and plugins updated — some database errors trace back to plugins that run unsafe queries on outdated table structures. Regular updates reduce exposure.

If you'd rather hand all of this off, Mend's $99/month Care Plan covers managed updates, daily backups, and uptime monitoring — so you know about problems before your visitors do.

When to Call a Professional

Work through the steps above and most database connection errors will resolve within 30 minutes. But call in a professional if:

• You've verified credentials, the server is up, and the repair tool finds tables it can't fix.
• The database is accessible but large chunks of content are missing after a repair.
• The error returns within hours or days — pointing to an underlying server or security issue.
• You don't have FTP/SFTP access and can't reach wp-config.php.
• Your site was recently hacked and you're not certain the database itself wasn't tampered with.

In any of these situations, Mend's Emergency Rescue service gets a senior engineer working on your site — usually the same day — with a backup-first workflow and a plain-English report of exactly what was wrong and what was fixed. Flat price, no hidden fees, and fixed or your money back.

For a wider reference on errors that take your site offline, bookmark our WordPress fix guides — they cover everything from the white screen of death to 500 internal server errors, all with the same step-by-step structure.