TLDR
“Error establishing a database connection” in WordPress almost always means one of three things: your wp-config.php credentials are wrong, your database server is down or overloaded, or the database itself is corrupted. Ninety percent of cases are fixed in under ten minutes by checking the credentials and refreshing the database server.
This post walks through the fix in order of likelihood, shows how to repair a corrupt database safely, and ends with a short exercise so you know exactly where to look the next time the error lands at the worst possible moment.
The page loads, and instead of your site you see a stark white screen with the sentence “Error establishing a database connection.” No header, no branding, no admin. The site is, for visitor purposes, completely offline.
Panic is the wrong first move. This specific error has a small set of causes, and the fix is almost always quick once you know which one you are looking at. This guide walks through them from most common to least.
What the error actually means
WordPress stores everything in a MySQL or MariaDB database: posts, pages, users, plugin settings, WooCommerce orders. Every page load requires WordPress to connect to that database. This error means the connection attempt failed before it could read anything. PHP loaded, WordPress started, and then hit a wall.
The three possible walls are:
- Credentials are wrong. The username, password, or database name in
wp-config.phpno longer matches what the database server expects. - The database server is unreachable. The MySQL server is down, restarting, or overloaded. Your host may be rebooting or may have throttled you.
- The database itself is corrupted. One or more tables have become unreadable. Rare, but it happens after a host crash or a botched update.
Step 1: check your credentials
In your hosting file manager or via SFTP, open wp-config.php. Look for four lines near the top:
DB_NAME, the database nameDB_USER, the database userDB_PASSWORD, the passwordDB_HOST, usuallylocalhostor a specific server name from your host
Log into your hosting control panel (cPanel, Pressable, WP Engine, Kinsta, SiteGround). Find the database section and compare each value. If you cannot find the password, most hosts let you reset it in one click. Paste the new password into wp-config.php, save, reload your site.
Step 2: test if the database server is alive
If credentials look right but the error still shows, check whether the database is actually up. In your hosting dashboard, look for a “Database status” or “Server status” page. If the database is offline or restarting, give it five minutes and try again.
If your host has a status page, check it for recent incidents. Pressable, Kinsta and WP Engine all publish real-time status. If there is a current incident, the wait is the fix.
On shared hosting, the most common cause is your site has exceeded its database connection limit (often because of a traffic spike, a misbehaving plugin, or a bot). Raising the limit or restarting the database usually clears it. Your host support can do both in minutes if you raise a ticket.
Common mistakes beginners make here
- Editing
wp-config.phpwithout a backup. One stray character breaks everything. Copy the file first. - Entering the wrong
DB_HOST. On most shared hosts it islocalhost, but some use127.0.0.1, a full hostname, or a non-standard port. Copy exactly what your host dashboard shows. - Using phpMyAdmin to “repair” the database at random. Only run the Repair action on tables that are actually flagged as crashed. Random repairs can make things worse.
- Reinstalling WordPress to fix a database error. A fresh WordPress install cannot connect to a broken database either. Fix the database, not the files.
Step 3: repair a corrupt database
If credentials are right and the server is up, a corrupt table is the next suspect. WordPress has a built-in repair tool you can enable temporarily.
- Open
wp-config.phpin your file manager or SFTP. - Add this line anywhere before the That’s all, stop editing comment:
define('WP_ALLOW_REPAIR', true); - Visit
yourdomain.com/wp-admin/maint/repair.phpin a browser. You do not need to be logged in, which is why you remove this line afterwards. - Click Repair Database. Wait for the process to finish.
- Remove the
WP_ALLOW_REPAIRline fromwp-config.phpand save. Reload your site.
If the built-in repair does not help, the WordPress debug guide covers how to enable full error logging. A line in debug.log will usually name the broken table, which you can then repair directly from phpMyAdmin.
If nothing works: call your host
Once you have verified credentials, confirmed the server is up, and run the repair tool with no joy, the problem is on the hosting side. Raise a ticket with your host, quote the exact error message, and mention you have already checked wp-config.php credentials. They can run deeper diagnostics that are not visible to you.
Try it yourself this week
Know the fix flow before you ever need it, not at 9am on a Monday.
- Open your site’s
wp-config.phpin your host file manager. Note where the DB credentials live. - In your hosting dashboard, find the database section. Screenshot the database name, user, and host.
- Find your host’s status page or incident feed. Bookmark it.
- Write a three-line runbook to yourself: “Check wp-config credentials, check host status, raise ticket if neither.”
Five minutes of preparation, ten minutes to resolve the real thing when it arrives.
Prefer a human to help?
If the steps above are not enough, or you are short on time, the team behind WP Clipboard runs a Liverpool WordPress agency that has been fixing sites for small businesses and charities since 2012. Fixed-price quotes, no long tie-in.
Visit Marketing The ChangeFrequently Asked Questions
Will I lose data because of this error?
Almost never. The error is a connection issue, not a data-loss issue. Your posts, pages, users, and orders are still in the database. Fixing the connection restores access to them.
Can this error be caused by a plugin?
Indirectly, yes. A badly written plugin can flood the database with connection requests until your host cuts it off. If the error appeared right after you installed or updated a plugin, that plugin is your first suspect.
Is it safer to edit wp-config.php or use my hosting panel?
The hosting panel, when it offers the same option. Pressable, Kinsta and a few others let you manage DB credentials from a GUI. If yours does not, editing wp-config.php is fine, just back it up first.
How long should a database connection error last?
If it is a host-side incident, usually under an hour. If it is a credentials mismatch or a corrupt table, it stays broken until you fix it. Past two hours without your host acknowledging an incident, raise a ticket and follow up.
Can I prevent this from happening again?
Partially. Keep your plugins lean (fewer database queries per request), upgrade to a host with database-level failover if you are on a mission-critical site, and make sure your backups include the database and have been tested with a real restore.