This message means WordPress could not establish or maintain the MySQL connection required to load site data. The cause may be wrong credentials, unavailable MySQL, a host/socket mismatch, exhausted connections or damaged database infrastructure.
Do not reinstall WordPress or import an old backup first. Those actions can overwrite current content without repairing connectivity.
Define the outage scope
Test the public site, wp-admin, another authorised database-backed site on the same server and the hosting database panel. Record exact time and whether the failure is constant or intermittent.
If only one WordPress installation fails, focus on its configuration and database user. If every database site fails, investigate MySQL service and server capacity.
Avoid repeated refreshes during connection saturation.
Preserve configuration safely
Back up wp-config.php and record DB_NAME, DB_USER, DB_HOST structure without copying the password into tickets.
define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_HOST', 'localhost' );Check for hidden spaces, wrong quote characters and duplicate definitions after a migration. Rotate any password exposed during diagnosis.
Test credentials outside WordPress
Use cPanel/Plesk database tools or the MySQL client from the same server context. A successful remote desktop connection does not prove PHP can reach the configured socket/host.
Classify the result:
access denied -> credentials/grants
connection refused -> service/listener
unknown host -> DNS/hostname
too many connections -> capacity/leak
timeout -> network/firewall/loadNever place the password directly in shell history.
Check MySQL service and resources
Inspect service status, error log, disk, RAM, process list and connection count. MySQL may run but reject new work while recovering tables or at its connection limit.
Do not restart the service before capturing evidence and assessing active writes. A restart can roll back transactions and temporarily hide a leak.
On managed hosting, use the provider’s controls and incident logs rather than attempting unsupported service changes.
Verify database user grants
The user needs access to the intended database from the connection host. Migrations may recreate the database but not reassign the user or privileges.
Use cPanel/Plesk to attach the correct user with required WordPress permissions. Avoid granting global privileges or remote access to every address.
Confirm the WordPress table prefix exists in that database; a successful connection to an empty/wrong database produces a different symptom.
Inspect socket, port and hostname
localhost may use a Unix socket while 127.0.0.1 uses TCP. Hosting platforms can provide a separate database hostname or port.
Use the value documented by the host. Do not switch blindly; socket and TCP can have different users, firewalls and performance.
After DNS/database host changes, verify name resolution from the PHP server and account for cached records.
Check intermittent connection loss
Match failures with slow queries, connection spikes, backups and imports. Plugins that open unmanaged connections or long queries can exhaust capacity.
Use MySQL metrics and PHP logs to find the source before raising max_connections; each connection consumes memory.
For multi-node sites, confirm every web node uses the same intended database endpoint.
Check database drop-ins and persistent cache
Inspect wp-content/db.php and object-cache.php. Managed hosts and scaling plugins can replace WordPress’s normal database class or route reads to replicas. A stale drop-in copied during migration may reference an unavailable host even when wp-config.php is correct.
Temporarily remove a drop-in only through the provider/plugin’s documented process and after backup. Confirm immediate reads after writes do not go to a lagging replica, then verify every web node has the same current configuration.
Repair and verify writes
Correct the credential, grant, host, service or capacity issue demonstrated by evidence. Then test public pages, login, saving a controlled draft, media metadata and scheduled tasks.
Monitor MySQL errors and connection count after reopening. Recurring care should alert on disk, service health and connection saturation; a database connection fix is complete only when reads and writes remain stable.