WordPress Error Establishing a Database Connection: Causes and How to Fix It

If your WordPress site suddenly shows a blank white page with the message "Error establishing a database connection," your site's files are fine but WordPress cannot reach its MySQL or MariaDB database. This is different from a Cloudflare-side timeout like the one described in Cloudflare Error 522 (Connection Timed Out): Causes and How to Fix It, which happens between Cloudflare and your origin server. A database connection error happens on your own hosting server, after traffic has already reached it.

Quick answer: In most cases this error is caused by incorrect database credentials in wp-config.php, a database server that is temporarily down or overloaded, or a corrupted database table. Start by checking whether wp-admin still loads, then verify your database credentials, then check whether MySQL itself is reachable, and only then consider a database repair. Always back up your site before making changes.

Symptoms

The front end of your site shows only the text "Error establishing a database connection" on a white background.
wp-admin may show the same error, or may partially load with a different message such as "One or more database tables are unavailable."
The error appears suddenly, often after a plugin update, theme change, migration, or server maintenance, though it can also appear with no obvious trigger during traffic spikes.

Likely Causes

According to the WordPress.org support forums, this error commonly appears when the MySQL server is unavailable, and one frequent contributor is an excessive number of simultaneous database connections, since every database server enforces a maximum connection limit. Beyond that, community troubleshooting threads and hosting documentation point to a consistent set of causes:

Incorrect database credentials in wp-config.php — wrong database name, username, password, or host value, often after a migration or host change.
Database server down or unreachable — MySQL/MariaDB has crashed, is restarting, or is blocked by a firewall or port conflict on that server.
Too many concurrent connections — shared hosting plans in particular have hard limits on simultaneous database connections; a traffic spike or runaway plugin query loop can exceed that limit.
Corrupted database tables — can result from an interrupted update, an abrupt server crash, or a faulty plugin/theme writing bad data.
Corrupted WordPress core files — rare, but a damaged wp-db.php or similar core file can also produce this symptom.
Insufficient server resources — on constrained hosting plans, low memory or CPU limits can prevent the database from responding in time.

Diagnostic Order

Work through these steps in order rather than jumping straight to a database repair, since repairs and credential changes are best attempted only after ruling out simpler causes.

Check if wp-admin loads at all, and note the exact wording of any error there.
Confirm whether the issue affects every page or just specific ones.
Verify the database credentials in wp-config.php against your hosting control panel.
Check with your host (status page or support) whether the database server is currently up.
If credentials and server status check out, consider a database repair or file check as a next step.

Step-by-Step Fixes

Before making any changes below, back up your site files and database. Several of these steps involve editing configuration files or running repair tools, and having a recent backup means you can undo a mistake safely.

1. Check whether wp-admin still loads

Try visiting yourdomain.com/wp-admin. If it loads normally, or shows a message about unavailable database tables rather than the full connection error, the problem is more likely a corrupted table than a bad credential or a down server, which changes which fix to try next.

2. Verify your database credentials in wp-config.php

Open wp-config.php, located in your site's root folder, using FTP/SFTP or your host's file manager. According to WordPress developer documentation, this file stores the database name, username, password, and host that WordPress uses to connect on every page load. Compare each value — DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST — against the database details shown in your hosting control panel (commonly cPanel's MySQL Databases section, or your host's equivalent panel).

Note that DB_HOST is usually localhost, but some managed WordPress hosts run the database on a separate server, in which case the value will be different. If you're unsure, check with your host rather than guessing.

Warning: When editing wp-config.php, change only the values inside the quotation marks. Altering other parts of the file can break the site further. Save a copy of the original file before editing, and edit only one value at a time so you can identify what fixed the issue.

3. Confirm the database user has the correct permissions

In some cases the credentials are correct, but the database user has lost or never had privileges on that specific database. In cPanel or a similar panel, check that the database user is assigned to the database with full privileges. This is a common issue after a manual migration or a partial account restore.

4. Check whether the database server itself is reachable

If credentials and permissions look correct, the database server may be down, overloaded, or unreachable. Try logging into phpMyAdmin (or your host's database tool) directly. If it also fails to connect, or times out, the problem is very likely server-side rather than something in your WordPress files, and it's time to check your host's status page or contact support.

If phpMyAdmin loads and you can browse your tables normally, the database server is running, which narrows the problem down to WordPress-side files, plugins, or a specific corrupted table rather than the server itself.

5. Rule out a plugin or theme conflict

A faulty plugin or theme can occasionally interfere with database queries. To test this without needing wp-admin access, connect via FTP/SFTP and rename the wp-content/plugins folder (for example, to plugins-disabled). This deactivates all plugins at once. If the site loads afterward, rename the folder back and reactivate plugins one at a time to identify the culprit. If it doesn't help, rename the folder back before moving on.

6. Run the built-in database repair tool

If the database connection itself tests fine but WordPress still reports table problems, WordPress includes a repair tool. Add this line to wp-config.php, just above the line that says "That's all, stop editing":

define('WP_ALLOW_REPAIR', true);

Then visit yourdomain.com/wp-admin/maint/repair.php in your browser and choose either "Repair Database" or "Repair and Optimize Database."

Warning: This repair page does not require a login. Anyone who knows or guesses the URL can access it while the line is present in wp-config.php. As soon as the repair finishes, remove the WP_ALLOW_REPAIR line from wp-config.php to close that access.

If you're comfortable with SSH and your host supports WP-CLI, the equivalent commands are wp db check and wp db repair, which run the same underlying repair process without exposing a public URL.

7. Replace core WordPress files

If none of the above resolves the error, corrupted core files are a less common but possible cause. Download a fresh copy of WordPress from wordpress.org, unzip it locally, and delete the wp-content folder and wp-config-sample.php from the extracted copy. Upload the remaining files over your existing installation via FTP/SFTP, overwriting the current core files. Do not upload wp-content, since that folder holds your themes, plugins, and uploaded media — overwriting it would remove your customizations.

8. Restore from a backup

If the database appears genuinely corrupted beyond what the repair tool can fix, restoring your most recent full backup (files and database) is often faster and safer than continuing to troubleshoot manually. Confirm with your host or backup plugin documentation how to perform a restore correctly, since this will overwrite current data with the backup's contents.

Verification

After each fix, reload your site in a private/incognito browser window to avoid cached error pages. Then confirm that both the front end and wp-admin load normally, that recent posts and settings are intact, and that you've removed any temporary debugging lines (like WP_ALLOW_REPAIR) from wp-config.php.

When to Contact Hosting Support

Contact your hosting provider if phpMyAdmin or the database itself won't load at all, if you suspect the MySQL/MariaDB service has crashed on the server, if you're on shared hosting and suspect you're hitting a connection limit, or if you don't have confident access to edit wp-config.php or run repairs safely. Hosts can typically confirm database server status, connection limits, and correct DB_HOST values much faster than trial and error from your end.

FAQs

Does this always mean my content is lost?

No. In most cases the content is intact; WordPress simply can't reach it right now due to a credentials mismatch, a down database server, or a connection limit. Actual data loss is uncommon and usually tied to a specific corrupted table or a bad restore.

Why did this start right after I moved hosts?

Migrations frequently leave old database credentials in wp-config.php. Since a new host almost always issues a new database name, username, and password, this is one of the first things to check after a migration.

Is it safe to leave WP_ALLOW_REPAIR in wp-config.php?

No. The repair page it enables can be accessed by anyone who knows the URL, without logging in, so it should be removed as soon as you're done using it.

Could my hosting plan simply be too small?

Yes. On resource-limited shared hosting, traffic spikes can exceed the maximum simultaneous database connections allowed, producing this exact error. If it recurs during traffic spikes, ask your host about your plan's connection limits or consider upgrading.

Search This Blog

TechCorner HQ