Error establishing a database connection means WordPress could not establish the database access it needs. It does not, by itself, mean your database is corrupted or lost. Start by distinguishing a configuration mismatch, an unreachable database service, and a capacity problem before trying repairs or restoring an older copy.
The WordPress common-errors reference identifies database configuration and hosting problems among the causes. Your next action should follow the host's actual database error, not a generic repair button found in a tutorial.
Record the Scope and Recent Change
Check whether the error affects every uncached page, only one installation, or several sites on the same hosting account. A cached homepage can continue to look healthy while new dynamic requests fail. Record the first observed time and any deployment, migration, password rotation, storage alert, or traffic surge around it.
Ask the host to inspect the database service and application connection attempt. Useful evidence includes access denied, connection refused, name-resolution failure, too many connections, storage exhaustion, or an explicit table error. Do not publish database hostnames, usernames, passwords, or the full wp-config.php file in a support forum.
Follow the Error to the Right Layer
| Host evidence |
Investigate first |
Avoid doing blindly |
| Access denied |
Effective username, password, grants, source host |
Restoring old site content |
| Refused or timed out |
Service health, network route, firewall |
Changing every password |
| Too many connections |
Worker demand, stuck queries, host limits |
Raising limits without capacity review |
| Storage full |
Disk and database storage condition |
Deleting database files manually |
| Explicit table damage |
Backup and engine-specific recovery plan |
Running blanket repair operations |
Some hosts inject credentials through environment settings rather than keeping their final values directly in wp-config.php. Confirm the effective configuration through the host's supported tooling. A file that looks correct may be overridden by deployment variables, or may belong to a different document root.
Explanatory worksheet. Fill in your own evidence; no customer results are represented.
Fix Configuration Without Creating a Second Outage
For a migration, compare the destination database name, connection endpoint, account grants, and secret reference with the destination host's instructions. Do not assume localhost is correct for every provider. If a password rotated, coordinate the database account and every application consuming it; changing only one side preserves the failure.
Keep secrets out of command history and screenshots. If temporary access is needed, use the provider's approved credential-sharing process and remove it after the incident. Avoid exposing database administration tools publicly as a shortcut to remote troubleshooting.
For capacity failures, ask for connection and query evidence around the outage rather than immediately buying a larger server. A stuck task or burst of uncached requests may explain the demand. The WordPress performance diagnosis helps separate workload from front-end weight once connectivity is restored.
Preserve New Orders Before Any Restore
A restore replaces data with an earlier state. Establish the latest usable backup, the last successful order or submission, and which records would disappear. Where corruption is genuinely confirmed, have the host or database specialist select a recovery method appropriate to the database engine. Do not assume a repair command supports every table type.
If suspicious account or file changes accompany the outage, preserve evidence and investigate security too. Restoring a backup without understanding how access was lost can reintroduce the same problem or erase useful logs.
Verify Dynamic Requests After Recovery
Check administrator login, an uncached content page, and a controlled write such as a designated test form submission. For stores, use a sandbox or approved test-order procedure rather than charging a real customer. Confirm that existing recent records remain present and that connection errors stop recurring under ordinary load.
HandL WP can coordinate a database-connectivity investigation. Bring the timestamps, hosting error category, recent change, and backup coverage. Passwords and full customer exports are not needed in the initial brief.
Sources and release details checked September 24, 2026. Diagrams are explanatory; examples are synthetic.