If your WordPress site shows “Error establishing a database connection,” checking the database settings in wp-config.php is a sensible early step. The file contains the values WordPress uses to connect to its database, including DB_NAME, DB_USER, and DB_PASSWORD.
Check those values carefully—but don’t assume they are wrong just because the site is down. A database server outage, a hosting-account change, or a server resource problem can cause the same symptom. Start with quick, reversible checks, record the exact error and time, and make a backup before editing anything.
Before You Start: Record the Error and Protect the Site
Write down the exact message visitors see and when it began. For example: “Error establishing a database connection,” observed at 10:42 a.m. on October 15. Note whether the WordPress dashboard, the public site, or both are unavailable. If the message changes, record the new wording and timestamp too. These details help distinguish a credentials problem from a broader outage.
- Check the site in a private browser window and, if possible, from another device or network. Look at your hosting provider’s status page for a database or server incident. Before editing files, download a copy of wp-config.php and, if available, create a full site and database backup. Never paste database passwords into email, support tickets, screenshots, chat, or public forums.
If you can’t make a full backup because the site is already inaccessible, at minimum save a local copy of the file you plan to change. A copied file gives you a clear way to undo an edit.
What Is wp-config.php?
wp-config.php is WordPress’s main configuration file. It usually sits in the site’s WordPress root directory—the directory containing folders such as wp-admin, wp-content, and wp-includes. It tells WordPress which database to use and how to connect to it, among other things.
The database settings are commonly written as PHP constants, like this:
define( 'DB_NAME', 'example_database' ); define( 'DB_USER', 'example_user' ); define( 'DB_PASSWORD', 'replace-with-your-password' ); define( 'DB_HOST', 'localhost' );The values shown above are examples, not credentials to use. Your file may have different values, formatting, or comments. You may also see additional settings, including the database character set and table prefix. Don’t change those as part of a basic credential check.
Find the wp-config.php Location
The wp-config.php location depends on how WordPress was installed and how your host organizes websites. Common ways to access it include:
- Hosting control panel: Open the File Manager, then locate the document root for the affected domain. It may be named public_html, www, htdocs, or a folder named after the site. SFTP: Connect using your hosting account’s SFTP details and browse to the site’s document root. Use a reputable SFTP client and keep your login private. SSH: If your hosting plan provides shell access, navigate to the WordPress directory and list its files. Don’t run commands that overwrite or delete files unless you understand their effect.
In some installations, wp-config.php is one directory above the WordPress root. That is a supported arrangement: WordPress can find the file there. If you don’t see it in the first directory you open, check the parent directory rather than creating a new configuration file.
How to Check DB_NAME, DB_USER, and DB_PASSWORD
Open the correct site directory. Confirm that it contains the WordPress folders for the domain reporting the error. Sites on the same hosting account may each have their own configuration file. Make a copy before editing. Download wp-config.php and save it with a clear name, such as wp-config-before-check-2026-10-15.php. Store it somewhere private; it contains sensitive information. View the file securely. Use the hosting File Manager’s code editor or a plain-text editor on a computer you trust. Do not open it in a word processor that may add formatting. Find the database constants. Search for DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. Read each value exactly as written, including capitalization and punctuation. Compare with the host’s database records. In your hosting panel, look for a database or MySQL section that lists the database name and users assigned to it. Match those records with the values in the file. Close the file without saving if you are only inspecting it. A check alone does not require changing the configuration.Be aware that some hosts add an account prefix to database names and usernames. A name in the hosting panel might look like accountname_site, rather than simply site. Use the full value shown by the host.
What Each Database Constant Means
Constant Purpose What to compare DB_NAME The database WordPress should use. Check the full database name in the hosting panel. DB_USER The database account WordPress uses to log in. Confirm this user exists and is assigned to the database. DB_PASSWORD The password for that database account. Confirm it matches the current password. Panels may not display an existing password. DB_HOST The database server address WordPress connects to. Check the host’s required value; it may not be localhost.Some hosting panels hide saved passwords for security. If you can’t verify the current password, don’t try random alternatives. Ask your host how to confirm or reset the database user password, and whether a reset requires updating the WordPress configuration.
Check Whether the Credentials Actually Work
A value can look correct and still fail because the database user lacks permission, the password changed, or the database host is different. Use the hosting panel’s database tools to check that the database exists and the intended user is assigned to it with the permissions required by WordPress.
If your host provides phpMyAdmin, it can confirm that a database is present and accessible through the panel. However, a successful phpMyAdmin login may use your hosting account’s access rather than the exact credentials stored in wp-config.php. Don’t treat that alone as proof that WordPress’s database user and password are correct.
When the host confirms that the password must be reset, use its documented process and coordinate the change. Changing a database user’s password without updating the matching value in wp-config.php can keep the site offline. Conversely, changing the file to a password that was never set on the database account won’t help.
Check Hosting and Server Health Before Changing Credentials
Database credentials are only one possible cause of a connection error. Before editing the wordpress config file, check for signs of a wider hosting issue:
- Is the hosting account active and within its storage, inode, and resource limits? Does the hosting control panel show the database server as available? Did the host recently migrate the site, change the database host, restore a backup, or reset a database password? Are other sites on the same account also unavailable? Do the hosting error logs show database connection failures, resource exhaustion, or server errors at the time you recorded?
If several sites on the same server fail at once, or the host reports a database outage, editing credentials is unlikely to fix the underlying problem. Preserve your notes and wait for the provider’s incident update mysql server down wordpress rather than making speculative changes.
If a Change Is Needed, Make One Controlled Edit
Only change a value after you have confirmed the correct value with the hosting panel or provider. Avoid replacing the whole file, changing multiple settings at once, or copying configuration snippets from an unrelated website.
Confirm your backup copy is saved securely. Change only the specific constant that the host has verified is incorrect. Preserve the PHP syntax, including quotation marks, commas, and parentheses. Save the file, then test the site in a private browser window. Record what you changed, when you changed it, and whether the visible error changed.Fix Record: Database Setting Update
What changed: Record the exact constant updated—for example, “Changed DB_HOST to the value confirmed in the hosting panel.” Do not record the password itself in an unsecured log.
How to roll back: Restore the saved pre-change copy of wp-config.php using the hosting File Manager or SFTP. If the database password was also reset at the host, restoring the old file alone may not restore access; coordinate the database and file settings together.
When to Ask Your Host for Help—With Specific Details
Contact the hosting provider if you can’t confirm the database name, user assignment, password-reset process, or DB_HOST value, or if the database server appears unavailable. Give support a concise, useful report rather than sending your password.
- “The site displayed ‘Error establishing a database connection’ at 10:42 a.m. on October 15.” “I checked the site’s wp-config.php and compared the database name and user with the control panel.” “Please confirm whether the database server is healthy, whether this database user is assigned to the database, and what DB_HOST value this account should use.” “If the database password needs a reset, please provide the safe procedure and tell me whether the change affects other applications.”
Share the domain and account details through the provider’s secure support channel. Never include the actual DB_PASSWORD in a ticket or message.
Common Mistakes to Avoid
- Assuming every WordPress database host is localhost. Changing a password in one place but not the other. Editing a different site’s wp-config.php on a multi-site hosting account. Adding a second set of database constants instead of correcting the existing ones. Installing troubleshooting plugins during an outage or making unrelated updates. Sharing screenshots that expose database credentials.
Summary
To check DB_NAME, DB_USER, and DB_PASSWORD, locate the correct wp-config.php, make a private backup, and compare its database settings with the hosting panel. Remember to verify DB_HOST, database-user assignment, and server health as well. Record the exact error and timestamp, make only confirmed changes, and keep a clear rollback path. If the host must reset the database password or investigate server availability, give support the details of your checks—but never send the password itself.