Fix a 403, 500 or database connection error on your site

These three errors look equally catastrophic and are equally recoverable. Each one narrows the cause down more than it feels like it does. Here is what each means and the checks in the order most likely to find it.

“Error establishing a database connection”

WordPress says this, other apps phrase it differently, but it always means the same thing: the site code runs fine and cannot reach its database. That is a configuration problem, not data loss. Your database is still there.

Check three things, in order:

1. The credentials. The database name, username and password in your app’s config (wp-config.php for WordPress, .env for Laravel) must match what the panel’s Databases page shows. If someone recently changed the database password in the panel, the config still has the old one.
2. The host must be localhost, not 127.0.0.1. Sites here run in their own containers, and inside a container 127.0.0.1 is an empty loopback with no database on it. localhost routes through the socket your site is actually allowed to use. This one detail explains most “my credentials are right but it will not connect” cases, and it is specific to properly isolated hosting.
3. Restart the container. Your site’s overview page in the panel has a Restart container quick link. If the config is right and it still will not connect, restart and check again before debugging further.

403 Forbidden

The server understood the request and refused it. The usual suspects:

• No index file. A directory with no index.php or index.html in it returns 403 rather than listing its contents. If you just uploaded a site, check the files landed in public_html itself and not in a folder inside it.
• The IP manager. Your site’s Security page can allow or block visitors by IP address. A block rule that is broader than intended returns 403 to real visitors. If you have ever touched that screen, look there early.
• .htaccess rules. Deny rules, country blockers and security plugins all write to .htaccess. Rename the file to .htaccess.off for a moment and reload. If the site comes back, the problem is a line in that file, and you can restore it section by section.

500 Internal Server Error

Something in your site’s code or configuration crashed while handling the request. The error page is deliberately vague to visitors, but the cause is logged.

• .htaccess again, especially after a move. Directives copied from another host frequently reference modules or handlers that do not exist here, and handler lines from old cPanel setups are a repeat offender because they can stop PHP executing entirely. Same test as above: rename it, reload, restore in pieces.
• PHP version mismatch. Old code on a new PHP version, or new code on an old one, crashes on startup. Your site’s PHP version is shown on its overview page and switching takes one click. The PHP version guide covers how to test a switch safely.
• A plugin or theme, on WordPress. If the error started right after installing or updating something, that something is the cause. WP-CLI over SSH can disable plugins without needing the admin panel that the error just took down: wp plugin deactivate --all, then reactivate one at a time.
• Exhausted limits. A site that dies only on heavy pages, big uploads or long imports is hitting a PHP memory or execution limit rather than a bug.

If the whole site became a 404 instead

A missing site is a different situation from a broken one. If the domain suddenly serves nothing at all and there is an unpaid invoice on the account, check billing before debugging DNS. Suspended hosting stops serving; paying the invoice brings it straight back.

When to hand it to us

If you have been through the list and the site is still down, open a ticket from the client area with the exact error and what you last changed. The error logs on our side usually name the failing line, and staring at a vague 500 alone is not a good use of your evening.