Fix “Error Establishing a Database Connection” in WordPress

The message can appear site-wide, only in wp-admin, or intermittently under load. Those scopes matter. A permanent failure after migration points toward configuration or routing; brief bursts point toward availability or connection pressure.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: separate bad credentials, an unreachable database, an overloaded server, and damaged tables before changing wp-config.php.

What the symptom narrows down

• DB_NAME, DB_USER, DB_PASSWORD, or DB_HOST no longer matches the database service.
• The database process or network path is unavailable.
• The server is accepting connections but has exhausted capacity or a required table is damaged.

The branches are ordered to protect the strongest evidence around this possibility: dB_NAME, DB_USER, DB_PASSWORD, or DB_HOST no longer matches the database service. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Database symptoms should be divided into reachability, authentication, capacity, integrity, and query behavior; repair tools address integrity; they do not correct a full disk, an exhausted connection pool, or an unreachable host; in this guide, the practical goal is to separate bad credentials, an unreachable database, an overloaded server, and damaged tables before changing wp-config.php.

Evidence to collect before the fix

1. Preserve wp-config.php, then compare its host and database name with the hosting control panel without publishing credentials.
2. Use wp db check when WP-CLI can bootstrap, or the host’s database client with the same account.
3. Check database uptime, connection count, disk space, and error log at the failure time.
4. Determine whether a static file still works and whether the error is intermittent.

The sequence moves from observation toward intervention. Preserve the result of the final check—determine whether a static file still works and whether the error is intermittent—because it provides a useful comparison after the repair.

Apply fixes in the safest order

1. Correct only the mismatched credential or host value and rotate an exposed password.
2. Restart or recover the database service through the host if it is unavailable.
3. Repair a table only after a database backup and only when the database reports that table as damaged.

Before applying “Correct only the mismatched credential or host value and rotate an exposed password,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can load the front page, wp-admin, and a query-heavy archive; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Prove recovery

• Load the front page, wp-admin, and a query-heavy archive.
• Run wp db check and confirm scheduled jobs can also connect.
• Monitor new database errors rather than treating one successful page as closure.

One successful refresh is not closure. Keep the incident open until you can also run wp db check and confirm scheduled jobs can also connect, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

Before a database-changing repair, record table sizes and status, create a restorable dump, and know which file backup belongs to it; give a host the error timestamp, database endpoint, anonymized error code, connection metrics, and whether failures are constant or load-dependent; include the result of this first observation: preserve wp-config.php, then compare its host and database name with the hosting control panel without publishing credentials.

State what was tested, including the result of “Preserve `wp-config.php`, then compare its host and database name with the hosting control panel without publishing credentials,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

wp db check
wp option get siteurl
wp core version
wp eval 'echo $GLOBALS["wpdb"]->db_version(), PHP_EOL;'

Shortcuts that create a second incident

• Never paste wp-config.php into a public support thread.
• Do not enable WordPress’s repair mode and leave its unauthenticated endpoint exposed.

Primary references

• WordPress common errors — official reference consulted for this guide.
• WP-CLI database commands — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Correct only the mismatched credential or host value and rotate an exposed password”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.