The error establishing a database connection message means WordPress cannot talk to its database. The site cannot fetch posts, pages, settings, or login data, so the front end and the dashboard both break.
This sounds severe, but it usually comes down to a short list of causes: wrong credentials in the config file, a damaged database, an overloaded server, or a host outage. If you check those one by one, the answer usually shows up quickly.
Treat this one like a methodical diagnosis, not a guessing game. WordPress databases are resilient, and many cases are fixed with a credential correction or a simple repair rather than a full restore.
If you have just migrated the site or changed passwords, start there first. That is the most common place for this error to begin.
What Usually Causes It
The first thing to suspect is a bad database value. A single typo in the database name, username, password, or host can break the connection immediately. That often happens after a migration or password reset.
If the settings are correct, the database may be corrupted or one of its tables may be damaged. Heavy traffic or a resource limit can also make the server fail to respond in time. And sometimes the host itself is having a temporary outage.
The important part is not to assume the worst. This error is common, and common problems tend to have plain fixes. Start with the credentials because they are fast to verify and easy to correct.
Step-by-Step Fix
Step 1: Check the database credentials in your config file
Open the config file and confirm the database name, username, password, and host exactly match the values from your hosting account. This is the fastest and most common fix, especially after migrations or credential changes.
If you changed hosts recently, also check that you are pointing to the correct database server. Some hosts use localhost, while others use a specific hostname. One wrong field is enough to trigger the connection error.
While you are there, confirm there is no typo in the table prefix section if your install uses a custom prefix. A mismatch there can make a valid database look broken.
DB_NAME
DB_USER
DB_PASSWORD
DB_HOST
// confirm these values match your hosting accountStep 2: Repair the database
If the credentials are right, the database itself may need repair. WordPress can expose a repair page when you add the repair constant and visit the maintenance URL. Use it as a temporary tool, not a permanent setting.
After the repair finishes, remove the constant right away. Leaving repair mode open longer than needed is unnecessary. If the repair page reports damaged tables, note which tables it lists so you can confirm the site behaves normally after the fix.
If the repair page itself will not load, that is still useful information. It suggests the problem is deeper than a small table issue and pushes you toward hosting or backup recovery.
define('WP_ALLOW_REPAIR', true);
// Visit the repair page after saving the file:
// /wp-admin/maint/repair.phpRemove the repair constant after the repair is complete. It should only exist for the repair window.
Step 3: Check whether the host is down
If the site still cannot connect, the hosting side may be the problem. Check the provider status page and reach out to support. If the database service is unavailable, there is nothing to fix inside WordPress until the host restores service.
This step matters because it keeps you from wasting time inside the wrong layer. If the server is down, the site can look broken even though the WordPress files are fine. Waiting for service to return is often the correct move.
If support confirms an outage, ask whether the issue is limited to the database host or part of a broader incident. That gives you a realistic timeline and tells you whether you should wait or restore elsewhere.
Check the hosting status page and contact support if the database service is unavailable.Step 4: Check the tables in phpMyAdmin
If the database opens but the site still fails, look for damaged or missing tables. phpMyAdmin can show whether the database structure is intact. A single bad table can prevent WordPress from loading.
Run a table check, note any corruption warnings, and repair the affected tables if your host allows it. Afterward, test the site again and confirm the homepage, login, and a few key admin pages all load cleanly.
If the table names look unfamiliar, compare them to a clean WordPress install. That can reveal whether the database was partially imported, partially restored, or simply damaged.
Open phpMyAdmin, select the WordPress database, and run a table check or repair on any damaged tables.Step 5: Restore from a known good backup
If the database is badly damaged or the error started right after a risky change, restore the last clean backup. This is especially helpful when the database structure is too far gone for a quick repair.
Managed hosts such as WP Engine and similar providers often include automatic backups, which makes rollback much less painful. Restoring from backup is not the first step, but it is the best safety net when the earlier checks do not solve it.
Before restoring, note what changed and when the error started. That helps you decide whether the restore should happen now or whether support can recover the database more precisely.
Restore the latest clean backup from your hosting control panel or backup system.How to Prevent It Next Time
This error is easier to live with when you already have a recovery habit. Keep your database credentials documented, make backups before migrations, and watch resource usage during traffic spikes or big campaigns. The point is to make recovery boring.
- Store the correct database values in a secure place.
- Back up before plugin, theme, or host changes.
- Use managed hosting with automatic backups when possible.
- Monitor traffic and resource usage before busy periods.
- Test restores occasionally so you know the backup actually works.
Common Mistakes
People usually make this error worse by jumping straight to a restore or changing random values. Slow down and confirm the layer that is actually failing.
It also helps to keep a short note about when the site last worked. That simple timestamp can save a lot of time during troubleshooting.
- Changing multiple credentials at once.
- Leaving repair mode enabled after the fix.
- Assuming the database is damaged before checking hosting status.
- Restoring an old backup without checking what changed.
- Ignoring the possibility of a temporary outage or server overload.
FAQ
Is this always a database problem?
Usually yes, but not always. The database may be fine while the host, credentials, or server resources are the real issue. That is why the order of checks matters.
Can I fix this without losing content?
Often yes. If the issue is credentials, hosting, or a repairable table problem, your content usually stays intact. A restore is only needed when the database cannot be recovered cleanly.
What file should I check first?
Start with the config file that stores the database settings. That is where WordPress gets the connection details. If the values are correct, move on to repair and hosting checks.
How do I know if the host is the problem?
If the credentials are correct and the database still does not respond, check the host status page and ask support to confirm the database service. A provider outage can look identical to a site-side failure.
Should I restore a backup right away?
Only after you check credentials, repair options, and host status. Backups are the safety net, but they are not always the first move. When used at the right time, they save hours.
Final Thoughts
This error is frustrating, but it is usually clear once you check the right layer in order. Start with the database settings, then repair, then hosting, then table integrity, then backup.
That sequence protects your data and saves time. In most cases, you are much closer to a fix than the blank message suggests. Stay calm and move through the list.
About The Author
I spent two hours on this error before finding that my host had silently changed the database hostname. The wp-config.php check step should be the first thing anyone does. Would have saved me a lot of stress.
Glad it helped. On Fix Error Establishing Database Connection, the big win is usually getting the first pass right and then refining from there. That tends to save a lot of time later.
Does the WP_ALLOW_REPAIR trick work on managed hosts like Kinsta? Or do they have their own database repair tool?
Kinsta has a built-in database tool in the MyKinsta dashboard under the site tools section, you can run a repair directly from there without touching wp-config.php. WP Engine has something similar. One of the advantages of managed hosting is that these tools are right there when you need them.
Bookmarked this. The point about checking if the host is down first is underrated. I once spent an hour debugging wp-config.php only to find out the entire data centre had an outage. Always check the host status page before touching any files.
Thanks for reading, Stefan Nowak. On Fix Error Establishing Database Connection, I would start with the basics and then tighten things up once you see how it behaves in practice. If you are already testing it, the main thing is to keep the setup simple enough to debug quickly.