Work out whether the database service, credentials, account permissions or WordPress configuration stopped the site from connecting.
Recognize the symptoms before changing settings
The same visible error can originate in different layers. Your first objective is to identify whether the failure is specific to a route, a user action, a hosting component or a recent change. Do not treat a browser message as a complete diagnosis.
- The site displays “Error establishing a database connection” before normal content loads.
- wp-admin may show the same error or a different database-related message.
- The incident can follow a hosting move, password rotation, resource limit or database outage.
Record the original URL, time of failure, browser or HTTP error and the last change that occurred before the issue began. These observations make later comparisons reliable, especially when caching or multiple servers are involved.
Before you change anything
If the site is taking payments or sending messages, confirm whether an operation may have already completed before resubmitting it. Make one isolated change at a time, then test the original failure again.
Diagnosis: find the layer that actually failed
Work through these plausible causes in evidence-first order. More than one can coexist, but fixing the first confirmed cause is safer than making several speculative adjustments.
Common underlying causes
- Database host, name, user or password no longer matches hosting configuration.
- Database server unavailable, too many connections or storage exhaustion.
- Database account permissions were changed during migration.
- A damaged table is suspected without evidence; repairing tables will not fix wrong credentials.
Three checks that narrow the problem
- Check your hosting database-service status and recent infrastructure notices.
- Confirm DB_HOST format (host, socket or port) with the provider; do not assume localhost.
- Determine whether multiple sites on the same database host fail at once.
The relevant response, request log and configuration source together provide better evidence than a generic error screenshot. If you cannot access logs, gather the failing URL and timestamp and request the corresponding records from your hosting provider.
How to interpret conflicting results
If the first check points toward database host, name, user or password no longer matches hosting configuration, focus on reproducing that condition without changing unrelated settings. A quick improvement after a targeted test is useful evidence but not yet proof that the root cause is removed.
If your second check suggests database server unavailable, too many connections or storage exhaustion, collect the corresponding service or application log and compare what happens immediately before and after the failed request. This prevents mistaking correlation for cause.
If neither case fits, consider a damaged table is suspected without evidence; repairing tables will not fix wrong credentials. Work from the outside in: DNS and connection, web server and proxy, PHP/WordPress runtime, then the affected plugin, theme or data. When a check gives inconclusive results, record that uncertainty instead of labelling it a confirmed fix.
Step-by-Step Troubleshooting
Choose the safest method for your access level. Use the Beginner tab for recovery and the Advanced tab for log-based diagnosis and targeted fixes.
Check host health before editing passwords
Open the hosting dashboard and inspect database availability, quotas and service alerts. If the database engine is down, contact the host with the failure time rather than rotating credentials.
Compare the WordPress configuration safely
Through a protected file manager, locate wp-config.php and compare the variable names against the credentials recorded in the hosting panel. Do not email or publish the value of DB_PASSWORD.
define( 'DB_NAME', 'your_database_name' );define( 'DB_USER', 'your_database_user' );define( 'DB_HOST', 'your_database_host' );Check the connection after correcting one mismatch
If you identify a changed credential, update only that value, save securely and reload the original page. If the account exists but lacks database privileges, ask the host to correct grants.
Differentiate credential failure from service failure
Use a hosting-supported database connection diagnostic or an approved mysql client with credentials supplied interactively, not on a shared command line. Note whether the result says authentication denied, unknown database or connection refused.
Inspect resource and database errors
If authentication succeeds, inspect server connection limits, storage and query overload. Investigate expensive jobs rather than immediately raising every limit.
Repair only a demonstrably damaged table
If the error explicitly identifies table corruption, back up first and follow your engine-specific repair procedure. Do not leave publicly accessible WordPress repair mode enabled.
How to verify the repair
Do not call a problem solved solely because one browser reload succeeds. Retest the exact workflow that failed, then include a normal public request and one administrator action. Keep the site cache and authenticated/anonymous behavior in mind.
- A fresh request loads the site without a database error.
- The database logs show successful connections without new authentication failures.
Complete the checklist below as you test. The progress indicator belongs to this article and is intended as a reading aid, not a guarantee of server health.
Solution Checklist
If it still fails: rollback and escalation
If the symptom remains, stop repeating the same changes. Save the newest error evidence and compare it with the pre-change state; the unchanged behavior is a useful clue that the current hypothesis was wrong.
- Restore the original config file if the replacement values were incorrect.
- Ask your provider to restore the database from a verified backup if data integrity was affected.
When escalating to your provider or developer, send the time, affected URL, relevant status/log excerpt, environment version and the specific changes already tried. Remove passwords, session cookies, personal information and secret keys from the report.
How to prevent the error from returning
- Use a controlled credential-rotation process across all applications.
- Alert on database connection saturation and disk usage before it becomes an outage.
After a successful fix, make a brief incident note: symptom, root cause, effective change, verification test and rollback instructions. This is much more useful than keeping a list of unverified tweaks.
Further reading: official documentation
This guide explains diagnostic choices rather than guaranteeing that one setting will work on every host. Verify the actual software versions, hosting environment and provider restrictions before applying examples.