When one WordPress site stops connecting to its database while other sites on the same hosting account still work, it is tempting to assume the server is fine and the problem must be inside WordPress. That is often true—but it is not proof. One website can have incorrect credentials, missing database permissions, a damaged database, or a site-specific hosting issue while fantasticlawyers.com its neighbors remain online.
Start with the fastest reversible checks. Don’t install random plugins, edit several settings at once, or delete database files. First record what you see, check whether the issue is temporary, and preserve a copy of the configuration before changing anything. This guide walks through a safe triage process, including how to check for a single database user issue, database permissions, or wrong credentials.
First, Capture the Error and the Time
Before troubleshooting, write down the exact message displayed in the browser and the time it appeared, including your time zone. Common WordPress messages include:
- “Error establishing a database connection” “One or more database tables are unavailable” A blank page or HTTP 500 error after a recent change A hosting-provider message saying the database server is unavailable
Also note whether the error affects the entire site, only the administration area, or just certain pages. Test the site in a private browser window and, if possible, from a different network. This helps rule out a stale browser response or a local network problem.
Keep a simple incident scratchpad: the error text, time, affected domain, recent changes, and each action you take. That record helps you undo a change and gives hosting support specific details if you need them.
Rapid Outage Triage: Check the Simple, Reversible Causes First
Check for a short-lived outage. Reload the page once or twice, then wait a minute. Avoid rapid repeated refreshes, which won’t repair a database connection and can add load. Check other sites and services on the account. Confirm whether they use separate databases or share one database server. A working site may be using a different server, database, or account. Review recent changes. Think about password changes, a site migration, a restore, a hosting-plan change, a domain move, or a security cleanup. A change immediately before the outage is an important clue. Check the hosting control panel. Look for a database-service notice, account limit warning, storage alert, or maintenance announcement. Check the site’s error log if your panel provides one.What changed: Nothing. These checks are read-only and are the safest place to start.
How to roll back: No rollback is needed.
Why One Site Can Fail While Other Sites Work
Websites on one hosting account do not necessarily share database credentials or permissions. Each WordPress installation may have its own database name and database user. Even when several sites use the same database server, each can connect independently.
That means working neighboring sites make a complete hosting outage less likely, but they do not rule out a problem affecting only this site. For example:
- This site’s database user may have been deleted or had its password changed. The user may exist but no longer have permission to access this particular database. The site may point to an old database name or hostname. One database may be damaged, full, or temporarily inaccessible while others are healthy. A single database user issue may affect every site that shares that user, while sites using separate users continue working.
Do not assume that a working site’s database details are suitable for the affected site. Copying credentials between installations can create a second outage or expose data.
Check the WordPress Database Settings in wp-config.php
WordPress reads its database connection settings from the wp-config.php file in the site’s main directory. The key settings are usually:
- DB_NAME — the database name DB_USER — the database username DB_PASSWORD — the database user’s password DB_HOST — the database server address, sometimes with a port or socket detail
Use your host’s file manager or secure SFTP access to view the file. Before editing it, download a copy to a secure location. Treat this file as sensitive: it contains credentials, so don’t paste it into a public forum, email it unprotected, or include it in a screenshot.
Compare the values with the database and user details shown in your hosting control panel. Check for common mistakes such as a misspelled database name, an outdated username prefix, an accidental space, or a password that was changed in the panel but not in WordPress. On many hosts, account names are automatically added to database names and usernames, so the full value may differ from the short name you expect.
Check DB_HOST carefully. It is not always localhost. Some hosts use a specific server name, and a migration can leave an old hostname in the file. Use the exact value provided by the host for this database, rather than guessing.
What changed: Nothing if you are only comparing settings. If you correct a value, change only the confirmed incorrect setting.
How to roll back: Restore the saved original wp-config.php copy. If the site goes down after an edit, put the original file back before trying another change.
Check for Wrong Credentials and Database Permissions
A wrong password is one of the most common causes of “Error establishing a database connection,” especially after a password reset or migration. But a correct password alone is not enough: the database user must also be assigned to the correct database and have the necessary permissions.
In the hosting control panel, find the database name used by this WordPress site. Confirm that the database user listed in DB_USER exists. Check that the user is assigned to this database, not just to another site’s database. Review the user’s permissions using the host’s documented WordPress setup. Do not grant broad access to unrelated databases. Compare the user’s current password with the value configured in WordPress. If you cannot verify it, use the controlled reset process below.Ask yourself this: control panels differ, so the labels may say “add user to database,” “manage users,” or “privileges.” follow the host’s instructions for assigning a user. If the user was removed or the permissions were reset during a migration, restoring the correct user-to-database assignment may resolve the issue.
If You Need to Reset the Database Password
Use the hosting panel to set a new password for the database user, then update the matching DB_PASSWORD value in wp-config.php. Coordinate the two steps so the values match. If you change the password in the panel but not in WordPress, the site will continue to fail. If you update WordPress first while the database still expects the old password, the site may fail until the panel change is complete.
What changed: The database user’s password, its database assignment, or a specific permission—only if the panel confirms that item is incorrect.
How to roll back: Restore the previous password in both places if it is still valid. Otherwise, set one new password and update both the hosting panel and wp-config.php to match. Keep the new credential in a secure password manager.
Check the Database and Hosting Server Health
Even when other sites are working, ask whether this database is reachable and whether the account has enough resources. Check the host’s status page and the affected account’s control panel for:
- Database server maintenance or connection errors Storage or inode limits that may prevent normal writes Account resource limits, such as CPU, memory, or process limits Database size limits, connection limits, or unusually high traffic Recent migration, restore, or database import failures
If you have shell access and are comfortable using it, a read-only connection test can help distinguish a WordPress configuration problem from a database access problem. Use the host’s approved MySQL client and connection details, and avoid putting passwords directly into command history. If you are unsure how to test safely, skip this step and ask the host to verify connectivity for the specific database and user.
Do not run repair commands or change database tables just because the site shows a connection error. A connection failure and a damaged table are different problems. Repair is relevant only when WordPress or the database reports table corruption, and you should have a current backup before attempting it.
When to Contact Hosting Support—and What to Say
If the credentials, database assignment, and hostname appear correct, ask the host to test the connection from the web server to this specific database. “My site is down” is less useful than a concise, evidence-based request.
You can send a message like this:
“At [time and time zone], [domain] began showing ‘[exact error message].’ Other sites on the account are working. Please check whether database [database name] is online and reachable from this site’s web server, whether database user [username] is assigned to it with the required permissions, and whether there are account limits, connection errors, or recent changes affecting this database. Please do not reset credentials or modify the database without confirming with me first.”
Share the database name and username through the host’s secure support channel if requested. Never send the database password in an ordinary support ticket unless the provider has a secure, documented process—and even then, ask whether a password reset is safer.
After the Site Comes Back
Confirm that both the public site and /wp-admin load. Test a few important pages, forms, and checkout or booking functions if the site uses them. Check the error log for recurring database messages, and review whether any recent change needs to be documented or reversed.
Finally, make sure you have a current backup of both the database and site files. Keep database credentials stored securely, limit each user to the databases it needs, and record which WordPress installation uses which database. These simple records can turn the next incident from a guessing exercise into a quick, controlled check.
Finding Likely next step Database name, user, password, or host differs from the control panel Correct only the confirmed mismatch, after saving the original configuration. User exists but is not assigned to this database Restore the intended database assignment and required permissions. Settings match, but the database is unreachable Ask the host to check this database’s connectivity, service status, and account limits. Several sites using one database user fail together Investigate a possible single database user issue, such as a changed password or revoked permissions.
The Safest Order of Operations
When one WordPress site fails and others on the same host work, avoid broad fixes. Capture the exact error and timestamp, check recent changes, inspect the affected site’s own wp-config.php, verify the database user and permissions, and then ask the host to test the specific connection if needed. Save a backup before editing, change one confirmed item at a time, and keep a rollback path for every change. That approach is faster—and far less risky—than guessing.