Short answer: WordPress could not connect to the database using the credentials and host in wp-config.php. That can be a wrong credential, a stopped database service, a connection limit or corruption — and the difference decides everything you do next. In most cases the data is intact.
Triage before touching files
- Does it affect one site or every site on the account? Every site down points at the database server, not your config.
- Is the host’s status page reporting an incident?
- Was there a migration, a password change or a deployment just before?
- Has the account hit its disk quota or its maximum connections?
Check the four values in wp-config.php
Open wp-config.php and confirm DB_NAME, DB_USER, DB_PASSWORD and DB_HOST against what your hosting panel shows. DB_HOST is the usual trap — it is localhost on many hosts but a specific server name or socket path on others. Do not overwrite the whole file with a fresh one: you would strip the table prefix, salts and environment constants. Compare values instead, and never paste the file’s contents anywhere public — it holds your database password.
Test the connection directly
If the credentials look right but it still fails, test whether the database itself responds. Log in to phpMyAdmin or your host’s database tool with the same DB_USER and DB_PASSWORD. If that login fails too, the credential or the user’s privileges are the problem. If it succeeds, the issue is in how WordPress reaches the server — often DB_HOST or a service that is down.
When a table is corrupt, not the connection
If the service responds but WordPress still errors on some pages, a table may be marked as crashed. WordPress has a built-in repair mode: add define('WP_ALLOW_REPAIR', true); to wp-config.php, visit /wp-admin/maint/repair.php, run the repair, then remove that line immediately — leaving it on exposes a repair endpoint to the internet. Take a database backup before running it.
Verify with a real page
Load the front end, sign in to the admin, open the post editor and run a search. A home page served from cache can hide a database that is still refusing writes, so test something that reads and writes, not just the cached front page.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
The message covers several different failures: invalid credentials, an unreachable database service, exhausted connections, disk pressure or damaged tables. The order of checks prevents a configuration guess from becoming data loss.
- Confirm whether every site using the same database server is affected.
- Compare DB_NAME, DB_USER, DB_HOST and privileges without publishing wp-config.php.
- Test the same credentials directly from the hosting database tool or command line.
- Check disk space, connection limits and the database service log before attempting table repair.
What must be verified
- Front end and admin queries both work.
- A controlled write persists and can be read back.
- No connection or crashed-table errors appear in the database log.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Does this error mean I've lost my data?+
In most cases, no — the data itself is intact, and the problem is a wrong credential, a stopped database service, a connection limit, or a corrupted table. Which of these it is changes what you do next, so triage the situation before assuming data loss.
Should I just replace wp-config.php with a fresh copy to fix the database values?+
No — overwriting the whole file strips out your table prefix, security salts, and environment-specific constants. Compare the DB_NAME, DB_USER, DB_PASSWORD and DB_HOST values against what your hosting panel shows instead of replacing the file wholesale, and never paste its contents anywhere public since it holds your database password.
My credentials in wp-config.php look correct, what's the next thing to check?+
Test the connection directly by logging into phpMyAdmin or your host's database tool using the same DB_USER and DB_PASSWORD. If that login also fails, the credential or its privileges are the actual problem; if it succeeds, the issue is in how WordPress reaches the server, often the DB_HOST value or a stopped service.
Is it safe to run WordPress's built-in database repair tool, and how do I use it properly?+
Yes, but only after taking a database backup first. Add define('WP_ALLOW_REPAIR', true); to wp-config.php, visit /wp-admin/maint/repair.php, run the repair, and then remove that line immediately afterward — leaving it in place exposes a repair endpoint to anyone on the internet.