How to Fix Error Establishing a Database Connection in WordPress

"Error establishing a database connection" is the WordPress white screen every site owner dreads: no posts, no admin login, just that one line of text. On Ultra Web Hosting it almost always comes down to something small and fixable, usually a credential in wp-config.php that no longer matches the database. This guide walks through every cause in order, from the wrong database password to a corrupted table, with the exact wp-config.php lines to check and the safe way to run a repair.

01. What the Error Actually Means

Every WordPress page is built on the fly by querying a MySQL/MariaDB database: your posts, pages, settings, users, and plugin data all live there. When you load a page, WordPress opens a connection to that database using the credentials in wp-config.php, runs its queries, and renders the result. "Error establishing a database connection" means that first step failed. WordPress could not reach the database, or it reached it but was rejected, so there is nothing to render and you get the bare error message instead of a page.

Because the front end and the admin area both need the database, a true connection failure takes down the whole site, including /wp-admin. That is actually useful information: if the error appears everywhere, the problem is the connection itself (credentials, host, or the database server). If it appears on only some pages, you are likely looking at a corrupted table, which we cover in Section 08.

02. The Most Common Cause: wp-config.php Credentials

WordPress keeps its database settings in a single file at the root of your site called wp-config.php. Open it in cPanel File Manager (Edit) or over SFTP and look for these four lines near the top:

define( 'DB_NAME', 'user_wp123' );
define( 'DB_USER', 'user_wpuser' );
define( 'DB_PASSWORD', 'your-database-password' );
define( 'DB_HOST', 'localhost' );

Any one of these being wrong produces the connection error. The usual triggers are a site migration (the new account uses different database and user names), a password change (someone reset the database user's password in cPanel but did not update wp-config.php), or a typo introduced while editing the file. Read each value carefully:

• DB_NAME is the exact database name, including the account prefix (on our hosting it looks like cpaneluser_dbname).
• DB_USER is the database user, also prefixed (cpaneluser_dbuser). This is not your cPanel login or your WordPress admin login.
• DB_PASSWORD is the password for that database user. It is case sensitive and often contains symbols, so watch for a missed character.
• DB_HOST is where the database lives. On our shared hosting this is localhost (see Section 04).

03. Confirm the Credentials Against cPanel

You now know what wp-config.php claims. Next, confirm those values against the source of truth, which is cPanel MySQL Databases.

1. Log in to cPanel and open MySQL Databases (under the Databases section).
2. Under Current Databases, confirm a database exists whose name matches DB_NAME exactly, prefix and all.
3. Under Current Users, confirm a user exists whose name matches DB_USER exactly.
4. If either name does not match wp-config.php, correct wp-config.php to match cPanel (do not rename the database, just fix the config line).
5. For the password, you cannot read it back in cPanel, so if there is any doubt, reset it. Under Current Users, click the user, set a new password, then paste that exact password into DB_PASSWORD in wp-config.php.

Resetting the password and updating wp-config.php in the same sitting is the single most reliable fix, because it removes the one value you cannot otherwise verify. Use a password without spaces to avoid copy-paste surprises.

04. DB_HOST Should Be localhost

On Ultra Web Hosting shared plans, the database server runs on the same machine as your site, so WordPress connects to it locally. The correct value is:

define( 'DB_HOST', 'localhost' );

Do not use 127.0.0.1, and do not use a remote hostname or IP unless our support team told you to (which only happens on specific VPS or dedicated setups). A migrated site frequently arrives with DB_HOST pointing at the old host's database server, which of course is unreachable from here, and that alone produces the connection error even when the name, user, and password are perfect.

05. Verify the User Is Attached to the Database

A database user and a database are two separate objects in cPanel. A user only has access to a database it has been explicitly added to, with privileges granted. If DB_NAME and DB_USER both exist and the password is right, but the user was never linked to that database (or lost its privileges during a migration), the connection is rejected exactly the same way a bad password is.

1. In cPanel MySQL Databases, scroll to Add User To Database.
2. Select your DB_USER and your DB_NAME from the two dropdowns and click Add.
3. On the privileges screen, tick ALL PRIVILEGES, then click Make Changes.
4. If the user was already attached, cPanel will tell you so, and this step simply confirms the privileges are in place.

Granting all privileges is correct for a normal WordPress install, because WordPress needs to read, write, and alter its own tables. The full walkthrough of linking a user, including the privilege list, is in article 122.

06. Check the Database Itself in phpMyAdmin

If the credentials are verified, the user is linked, and you still get the error, look at the database contents. It is possible the database exists but is empty, which happens when an import silently failed or the wrong (blank) database was created during setup.

1. In cPanel, open phpMyAdmin (Databases section).
2. In the left sidebar, click your DB_NAME to expand it.
3. You should see a list of WordPress tables, typically prefixed wp_: wp_options, wp_posts, wp_users, and so on.
4. If the database is empty (no tables), the data was never imported. Restore from a backup or re-import your SQL dump, then reload the site.
5. If the tables are present, the database is fine and you should move on to the repair and resource-limit sections below.

Our "How to Manage Your Database with phpMyAdmin" guide covers browsing tables and importing a SQL file if you need to bring the data back in.

07. Repair a Corrupted Database

If phpMyAdmin shows the tables but the site still errors, or you see a related message about a table being marked as crashed, a table may be corrupted. WordPress ships with a built-in repair tool, but you have to switch it on in wp-config.php first. Add this line anywhere above the "That's all, stop editing" comment:

define( 'WP_ALLOW_REPAIR', true );

Then visit the repair page directly in your browser (you do not need to be logged in):

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

1. Add the WP_ALLOW_REPAIR line to wp-config.php and save.
2. Open /wp-admin/maint/repair.php in your browser.
3. Click Repair Database, or Repair and Optimize Database if you want it to reclaim space as well.
4. Let it run through every table and report the results.
5. Remove the WP_ALLOW_REPAIR line from wp-config.php and save the file again.

If the built-in tool cannot fix a table, you can repair it manually in phpMyAdmin: open the database, tick the affected table, and choose Repair table from the "With selected" dropdown at the bottom of the table list.

08. One Page Works, Another Fails

Here is the nuance that confuses people: the connection error appears on some pages but not others. If the credentials were wrong, every single page would fail, because they all authenticate the same way. So when the home page loads but a specific post, category, or the admin dashboard throws the error, the connection is fine and one or more individual tables are corrupted.

A crashed wp_options table can break the admin while leaving cached front-end pages working. A damaged wp_posts table might break certain posts. The tell is the same error on a subset of URLs rather than the whole site.

Match your symptom to the correct column before you start fixing. A site-wide error is a credentials problem; a partial error is a corruption problem. Diagnosing the wrong one wastes time.

09. Resource Limits and Too Many Connections

The credentials can be perfect and the tables healthy, and you can still see the connection error intermittently if the account or the database server is overloaded. Every account on our shared hosting has resource limits (CPU, memory, and concurrent processes), and MySQL/MariaDB will refuse new connections once too many are open at once. When that happens, WordPress cannot get a connection and reports the same error, but only under load, and it clears when traffic drops.

• Intermittent error under traffic usually means you are hitting connection or resource limits, not a config problem.
• A "too many connections" message points at slow queries or a plugin holding connections open. Deactivate recently added plugins to test.
• Frequent 500 errors alongside the database error point at the account tripping its resource caps. See article 128 for how our resource-limit behavior surfaces as 500s.

Our platform enforces plan limits rather than letting one account starve the server, so the answer to persistent overload is to reduce the load (caching, fewer heavy plugins, optimized queries) or move to a plan with more headroom. If you suspect a single runaway query or plugin, disabling plugins one at a time is the fastest way to find it. A repeated critical error on the site can share the same root cause, and our "How to Fix There Has Been a Critical Error on This Website" guide covers reading the debug log to pin it down.

10. After a Migration, and When to Open a Ticket

Most connection errors we see arrive within a day of a site move, and they trace back to one of three things. Run this checklist after any migration:

1. Credentials updated: wp-config.php uses the new account's DB_NAME, DB_USER, and DB_PASSWORD, and DB_HOST is localhost, not the old host.
2. Database imported: phpMyAdmin shows the full set of wp_ tables in the new database, not an empty shell.
3. User linked: the new database user is attached to the new database with all privileges.

If you would like us to handle the move so these are set correctly from the start, our "How to Migrate a WordPress Site to Ultra Web Hosting" guide explains the process and what we take care of for you.

When the problem is clearly not WordPress-specific (any application on the account cannot reach the database, or command-line MySQL fails), you are looking at general database connectivity, and article 176 covers that broader "cannot connect to MariaDB/MySQL database" case.

Open a support ticket when: you have verified the credentials and linked the user but the error persists; you suspect a database server issue on our side (which is rare, but we can check the server logs); or you cannot recover the correct credentials and need help resetting them safely. Include your domain and the exact error text and we can usually pin it down fast.

Quick Recap: Fixing the Connection Error

If you only do a handful of things from this guide, do these, in order:

1. Check the four wp-config.php lines - DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST - and confirm each against cPanel MySQL Databases.
2. Make sure DB_HOST is localhost on our shared hosting, not 127.0.0.1 or a remote host from the old server.
3. Reset the database password in cPanel and paste the exact value into DB_PASSWORD when you are unsure.
4. Confirm the user is attached to the database with all privileges, then check phpMyAdmin shows the tables and not an empty database.
5. Repair a corrupted database with WP_ALLOW_REPAIR and /wp-admin/maint/repair.php, then remove the flag from wp-config.php right after.
6. Rule out resource limits if the error is intermittent under load, and open a ticket if credentials are correct but it still will not connect.

Last updated July 2026 · Browse all WordPress articles