WordPress shows this when it cannot reach its database. In most cases the cause is a credential mismatch in wp-config.php — here is how to confirm that in about two minutes, and what to check if it is something else.
Open wp-config.php in your site root and compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST against the values in your hosting control panel. If you have just migrated hosts, changed a database password, or restored from a backup, a mismatch here is the cause the large majority of the time.
If the credentials are correct, the next most likely cause is that the database server itself is down — check your host's status page before changing anything else.
WordPress stores nearly everything in a MySQL or MariaDB database: posts, pages, users, settings, WooCommerce orders. On every request it opens a connection using the credentials in wp-config.php. When that connection fails for any reason, it cannot render a page at all — so instead of a partial site, you get this one sentence.
That single message covers several distinct failures, which is what makes it confusing. Working through them in order of likelihood saves time:
Try loading /wp-admin/. If the front end shows the connection error but the admin shows something different — particularly a message about a database needing repair — the credentials are fine and you have a corrupted table. That single check splits the problem space in half.
Open the file at your site's root over FTP, SFTP or your host's file manager. You are looking for four lines:
define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_password' );
define( 'DB_HOST', 'localhost' );Compare each against your hosting control panel. Watch for a trailing space inside the quotes, a database name that lost its account prefix during migration, and a DB_HOST that is not localhost on your host. Take a copy of the file before editing it.
Check your host's status page and control panel. If you can open a database client such as phpMyAdmin and it also fails to connect, the problem is the server, not WordPress, and there is nothing to fix in your files. On shared hosting this is frequently a neighbouring account consuming resources, and it resolves on its own.
If the admin reported a table problem, add this line to wp-config.php just above the line that says it has stopped editing:
define( 'WP_ALLOW_REPAIR', true );Then visit yoursite.com/wp-admin/maint/repair.php and run the repair. Remove that line as soon as you are finished — while it is present the repair page is reachable by anyone, without logging in.
In your control panel, confirm the user in DB_USER is still assigned to the database in DB_NAME, with full privileges. Restores and migrations regularly recreate the database and the user correctly but lose the mapping between them, which produces exactly this error with credentials that look perfectly right.
If the error appears and disappears, especially under traffic, you are likely hitting a cap on concurrent connections. Look for a plugin running expensive queries on every page load, check whether caching is actually active, and ask your host what your limit is. This one is a capacity problem wearing a configuration problem's clothes.
If the database is genuinely corrupted and repair does not recover it, restore the most recent backup from before the error started. This is the point at which the quality of your backup routine decides how much of the day you lose — and it is worth noting which backup you restored and why, because if the cause was a compromise rather than a fault, restoring alone will not keep it fixed.
Two things change when the site that just went down belongs to a client. The first is that you need to know before they tell you. The second is that whatever caused it, your fastest route back is knowing exactly what changed and being able to reverse it without a full restore.
That is the practical case for snapshotting every change: a database restore costs you everything written since the backup, while reversing a single change costs you nothing. When the failure follows a change you made, the two are not close.
One-click undo covers how that works, and managing multiple WordPress sites covers running checks across a portfolio rather than site by site.
WordPress shows this message whenever it cannot connect to its database. The usual causes are incorrect credentials in wp-config.php (most often after a migration or host change), the database server being down, corrupted database tables, the database user losing its permissions, or the host's concurrent connection limit being exhausted during a traffic spike.
The two common explanations are a change on the host's side — server maintenance, a suspended account, a hit resource limit — or a corrupted table, which can develop from an interrupted write and only surfaces when that table is next read. Intermittent errors that clear by themselves usually point to connection limits rather than credentials.
They are in wp-config.php in your site's root directory, defined as DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. The authoritative values are in your hosting control panel under the databases section. If they disagree, the control panel is right and wp-config.php needs updating.
No. Localhost is common but far from universal — many managed and cloud hosts use a dedicated database hostname, an IP address, or a host with a non-standard port. Copy the exact value your host specifies rather than assuming localhost.
It can, though it is not the likeliest explanation. An attacker with file access can alter wp-config.php, and some attacks drop or damage tables. If credentials changed without anyone changing them, treat it as a possible compromise and work through a recovery checklist rather than simply restoring and moving on.
Scheduled health checks across every site, and one-click undo on anything that changed.
Start free