Fix "Error Establishing a Database Connection" in WordPress

Quick fix: WordPress can't reach its database. In order of likelihood, the cause is: the database service has stopped (often killed for lack of memory), the disk is full, the credentials in wp-config.php are wrong, the database has hit its connection limit, or tables are corrupted. Check the database service first with systemctl status mariadb (or mysqld).

Symptoms

Every page shows "Error establishing a database connection"
Sometimes it affects only /wp-admin, with a note that one or more database tables are unavailable
The error may come and go under heavy traffic

Step 1: Is the database server running?

# MariaDB (most current Linux distributions)
systemctl status mariadb

# MySQL
systemctl status mysqld     # RHEL family
systemctl status mysql      # Ubuntu / Debian

If it's stopped, start it and read its log to find out why it stopped:

systemctl start mariadb
journalctl -u mariadb --since "2 hours ago" --no-pager | tail -50

Was it killed for running out of memory?

This is the single most common cause on small servers. The kernel kills the largest process, usually the database, when memory runs out:

dmesg -T | grep -i -E "out of memory|killed process"

If you see the database listed, the server needs more RAM, a smaller database memory configuration, or fewer PHP workers. Restarting it only fixes the problem until the next traffic spike.

Step 2: Is the disk full?

df -h

A database can't start or write when its disk is full. If any filesystem is at 100%, follow our disk full runbook first.

Step 3: Check the credentials WordPress is using

From the WordPress directory, show the database settings:

grep -E "DB_(NAME|USER|HOST)" wp-config.php

Then test them directly, using the same user, host and database name:

mysql -u DB_USER -p -h DB_HOST DB_NAME

If this fails with Access denied, the password in wp-config.php doesn't match the database user. This often happens after a migration or a password change in the control panel. Update one to match the other. On cPanel, use MySQL Databases to reset the user's password and confirm the user is assigned to the database.

Also check DB_HOST. It's usually localhost, but on managed or split database setups it must point to the correct server.

Step 4: Too many connections?

If the error appears only under load, the database may be hitting its connection limit. Log in as an administrative user and compare:

SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';
SHOW VARIABLES LIKE 'max_connections';

If Max_used_connections has reached max_connections, look for the cause first: slow queries holding connections open, a traffic spike, or a bot hammering the site. Raising the limit without enough memory just moves the problem to Step 1.

Step 5: Repair corrupted tables

If the error mentions tables being unavailable, check and repair them. With WP-CLI:

wp db check
wp db repair

Without WP-CLI, run mysqlcheck on the database:

mysqlcheck -u DB_USER -p --auto-repair DB_NAME

WordPress also has a built-in repair page, enabled by adding define('WP_ALLOW_REPAIR', true); to wp-config.php. That page can be opened by anyone while the setting is active, so remove the line as soon as you're done.

Verify the fix

Load the site's front page and /wp-admin in a private browser window.
Confirm the database service is set to start at boot: systemctl is-enabled mariadb.
Watch the database log for a few hours to make sure it stays up.

Prevent it from happening again

Monitor the database service and site availability, so a crash pages someone immediately.
Size database memory and PHP workers to the server's actual RAM.
Keep disk usage below 80%, with alerts.
Put caching in front of WordPress to cut database load. See our WordPress performance review.