WordPress problem fix
WordPress cannot reach your database. Your posts, users, and orders are almost certainly intact — the site just can't read them. Most cases are resolved in under an hour once someone opens the right file.
"Error establishing a database connection" is WordPress telling you it tried to talk to MySQL and got no answer. It is a connection error, not a data-loss error — your content, users, and orders sit untouched in the database itself. The screen appears because WordPress cannot even boot the theme without a working database handshake. The six real causes, in the order we see them: wrong credentials in wp-config.php (most common after a host migration), the MySQL service is down on the host, the database user hit its max_connections cap under a traffic spike, a corrupted database table (a REPAIR run fixes it), the database host address changed (usually not "localhost" on managed hosts), or the disk is full and MySQL refused new writes. The fix is diagnostic: open wp-config.php, verify each credential against what the host currently shows, test the MySQL connection directly, and only then start repairing tables. Skipping the diagnostic and restoring from backup can overwrite a live database that was fine — do the ten-minute check first.
If any of these match, you are on the right page.
White page with only the sentence "Error establishing a database connection"
Same error appears on both the front end and /wp-admin
It started right after a host migration, hosting plan change, or password rotation
Site was fine, then died during a traffic spike or scheduled backup
Refresh sometimes loads the site briefly, then it fails again
You see "One or more database tables are unavailable" underneath the main message
The number one cause after a host migration or password reset. wp-config.php stores DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. If any of the four is wrong by a single character, the handshake fails and you get this exact error. The host's control panel is the source of truth — copy from there, not from an old backup.
The database process itself crashed or was restarted for maintenance. WordPress is fine, PHP is fine, the box is up — but MySQL is not answering on port 3306. On managed hosts this shows up in the status page. On unmanaged hosts (VPS, self-hosted) you'll see it via `systemctl status mysql`.
A traffic spike, a runaway bot, or a badly-written plugin opens more DB connections than the host allows and MySQL refuses new ones. The site works for some visitors and errors for others, then eventually errors for everyone. Common on cheap shared hosting where max_connections is 15–25 per user.
A crash mid-write, an unclean shutdown, or disk errors can leave a table in a corrupted state. The tell-tale sign is a second line under the main error: "One or more database tables are unavailable". WordPress ships with a built-in repair tool at /wp-admin/maint/repair.php — enable it in wp-config.php with WP_ALLOW_REPAIR = true.
"localhost" works on old shared hosting but almost no managed host. SiteGround, Kinsta, WP Engine, Cloudways, Pantheon, Hostinger — each has its own database hostname (often something like `us-east-1.rds.amazonaws.com` or `mysql.mysite.internal`). If you migrated from cPanel to managed hosting and kept wp-config.php as-is, this is your bug.
MySQL refuses to accept writes when the database partition is full. This is common on servers where uncontrolled logs, backups, or /tmp files eat the disk. `df -h` on the server confirms it in one command. Front-end reads sometimes work briefly before failing — a clue that writes are the problem.
The real method, in the order it works.
Read wp-config.php and copy the four DB constants: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. Do not guess — copy them exactly.
Log into the host control panel and compare against the database credentials shown there. Reset the user's password if there is any doubt and update wp-config.php with the new value.
Test the connection outside WordPress. From the host's SSH or database console: `mysql -h $DB_HOST -u $DB_USER -p $DB_NAME`. Success proves the credentials are right and the fault is inside WordPress (a plugin or a corrupted table). Failure narrows to credentials, host address, or MySQL being down.
If the second-line error mentions unavailable tables, add `define('WP_ALLOW_REPAIR', true);` to wp-config.php and visit /wp-admin/maint/repair.php. Run "Repair and Optimise". Remove the line immediately after — it's a public URL until you do.
Check MySQL status via the host's status page (or `systemctl status mysql` on a VPS). If it's down, restart it and check the disk with `df -h` before assuming the crash was a one-off.
Only after the diagnostic: if the database itself is corrupted beyond repair, restore the most recent verified backup. Never restore blind — a rollback can throw away hours of legitimate writes.
Real fix, from our work
A regional ecommerce client called us on a Black Friday morning with "Error establishing a database connection" across every page. Their previous host had 'helpfully' upgraded their MySQL user overnight and rotated the password without telling anyone. Nine minutes from the call to a working site: SSH in, pull the new password from the host's control panel, edit wp-config.php, done. No restore, no data loss, no missed orders — 43 checkouts in the queue processed as soon as the connection came back. If we had restored from backup instead of reading wp-config.php first, we would have thrown away those 43 orders. Diagnostic before restore, every time.
Written by Ali Yasin Jatoi
Founder of WebCare Studios. Ali has worked with WordPress for more than 10 years, including managing a Pearl Lemon internal fleet of 150+ sites with WP-CLI automation for updates, security cleanup, and malware removal. He has hands on experience across major hosts including Cloudways, A2 Hosting, Hostinger, and Bluehost.
Site down, hacked, or broken checkout gets a senior engineer within 4 hours. No ticket queues, no bots.
Flat quote up front. If we cannot get you back online, you do not pay. Risk sits with us, not you.
We work on a snapshot first and never touch your live database until the fix is verified safe.
Our founder managed 150+ Pearl Lemon internal WordPress sites. The errors you are seeing are ones we have closed hundreds of times.
Almost never. The error is a connection failure — WordPress cannot read the database, but the database itself (with your posts, users, orders, and media) sits untouched on the server. In the rare case of table corruption, WordPress's built-in repair tool fixes it without any data loss.
Not yet. Restoring from backup can overwrite legitimate data written after the backup point — orders, form submissions, comments. Always run the 10-minute credential check in wp-config.php first. Restore is a last resort, not a first move.
Intermittent failure means you have hit the max_connections cap or MySQL is thrashing under load. When connections free up, the site loads; when they saturate, the error returns. The fix is either upgrading the host plan, adding a persistent object cache (Redis), or auditing plugins for connection leaks.
Sometimes — if the cause is MySQL being down (host will restart it) or a max_connections spike that clears on its own. But every managed diagnosis starts with the four DB constants in wp-config.php, because credential drift is the single most common cause after any host-side change.
One-off emergency repair is $299 flat for this incident via our website repair service — you only pay when the site is back online. If you're on a WordPress care plan, it's included, no extra fee.
Three preventions cover ~90% of recurrences: monitor database connectivity with a synthetic check every 5 minutes (we do this on every care plan), enable Redis or Memcached to reduce per-request MySQL connections, and lock wp-config.php changes to a documented deployment process so credentials never drift silently after a host update.
Two fields. Email and your URL. A senior WordPress engineer reads it within minutes and replies on email and WhatsApp with what is wrong and what we will do next.
Real proof and field guides tied to "Error establishing a database connection".