How to Fix “Error Establishing a Database Connection” in WordPress

Quick fix: check the host’s database status first. If MySQL/MariaDB is running, compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php with the values in the hosting panel. Test the same credentials directly; do not reset or repair the database without evidence.

Back up wp-config.php before editing it. Never paste database credentials into a public support thread.

Determine whether the outage is temporary

Test the homepage and /wp-admin/. Check the hosting status page and control panel for a database incident, server restart, storage quota or account suspension.

If several sites using the same database service fail together, WordPress configuration is unlikely to be the cause. Wait for or escalate the infrastructure incident rather than changing every site password.

An intermittent error during traffic spikes can indicate exhausted database connections or a slow/overloaded server. Record timestamps and request logs from the host.

Verify the four database settings

Open wp-config.php and find:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );

Compare them character for character with the hosting panel. Watch for:

• an old password after a credential rotation;
• a staging database name on production;
• an incorrect database hostname or port;
• spaces accidentally added inside quotes;
• a restored wp-config.php from another environment.

DB_HOST is not always localhost. Managed hosts and container platforms often provide a service hostname, socket or hostname:port value.

Test the configured connection

If WP-CLI can bootstrap far enough, run:

wp db check

With MySQL client access, use the exact configured host and user:

mysql -h database-host -u database-user -p database-name

Enter the password interactively. Do not place it directly in the command because it can appear in shell history and process listings.

Interpret the result:

• Access denied: user/password mismatch or missing grants;
• Unknown database: wrong name or deleted database;
• Connection refused/timed out: server, hostname, port, firewall or network problem;
• Successful login: WordPress may be reading a different config file or failing later in bootstrap.

Confirm the database user has access

Hosting migrations sometimes copy the database but not the user grants. In the control panel, confirm that the configured user is assigned to the configured database with the privileges WordPress needs.

Do not create a new database or import a backup merely because the connection failed. That can produce an empty site alongside the real data and make recovery harder.

Check storage and resource limits

A full disk can stop MySQL, prevent temporary files or make tables unavailable. Check disk space, inode limits, database size and account resource usage.

If the error appears only under load, ask for:

• maximum and active database connections;
• slow query or database error logs;
• restarts around the failure time;
• CPU, memory and I/O saturation.

Increasing WordPress PHP memory will not repair an unavailable database server.

Repair tables only when corruption is reported

If wp-admin reports that database tables need repair, take a database backup and temporarily add:

define( 'WP_ALLOW_REPAIR', true );

Then visit:

https://example.com/wp-admin/maint/repair.php

Run the repair and immediately remove WP_ALLOW_REPAIR; the repair page does not require an authenticated WordPress session while enabled.

Use this only for table corruption. It does not bypass invalid credentials or a stopped server.

Check for different frontend and wp-admin behavior

If the frontend and wp-admin show different database messages, caching may be serving the frontend while admin requests reach the failed database. Purge nothing until you capture the behavior: the cached page proves that HTTP and DNS still work, not that the database is healthy.

Multisite and advanced caching setups can also use database drop-ins such as wp-content/db.php. Check whether a host or plugin installed one, and follow its vendor documentation.

Restore service and verify data

After correcting the cause:

1. load several frontend pages;
2. sign in to wp-admin;
3. create and delete a test draft;
4. run scheduled-event and Site Health checks;
5. test forms, orders or bookings that write to the database;
6. inspect logs for recurring connection failures.

If credentials changed, update secret storage and deployment configuration so the next release does not restore the old value. For a generic server failure without the database-specific message, use the WordPress 500 error checklist.