Error Establishing a Database Connection: The UK Fix List

Quick answer

Your files are fine. WordPress is running, it asked the database for your content, and the database did not answer. That is a connection failure, not a loss, and in most cases the content is untouched.

Work through the causes in order. The first two take about five minutes between them and resolve the majority of cases on UK shared hosting.

What the error actually is

A WordPress site is two things: the files, which are the software and your theme, and the database, which holds every post, page, setting and customer record. Each page view requires both.

When the files load but the database does not answer, WordPress cannot build the page and prints this message instead. It is deliberately vague because the underlying reason could be any of several things, and the software cannot tell which.

That vagueness is why people panic. The message sounds like the database is broken. Usually it is simply not answering.

The five causes, in order of likelihood

The ordering matters because the natural instinct is to start at the bottom of that table, with corruption, and that is the rarest cause and the one whose usual remedy risks the most.

Check one: is it you, or everyone?

Before touching anything, find out whether your host has an incident. Most UK hosts publish a status page, and a database outage affecting one server affects every site on it.

If there is a live incident, there is nothing to fix and any change you make now will be a change you have to remember to undo later. Wait.

If the host looks healthy, try loading the admin area at your domain followed by wp-admin. Occasionally the front end fails while the admin returns a more specific message, and a more specific message is worth a great deal here.

Check two: the credentials

WordPress stores its database details in wp-config.php in the site root. Four values matter: the database name, the user, the password and the host.

These change more often than people expect. A migration to new hosting, a restored backup carrying the old server’s settings, or a password reset in the hosting panel will each break the connection while leaving everything else perfect.

Compare the four values against what your hosting panel currently shows for that database. If any differ, that is your answer. Take a copy of the file before editing it.

One detail catches people out: the database host is not always localhost. Several UK hosts use a separate database server with its own address, and a site moved between providers will carry the wrong one.

Check three: connection exhaustion

If the site works intermittently, loading sometimes and failing at others, the likely cause is running out of available connections rather than anything being wrong.

This usually traces to a plugin doing more database work than the hosting allows, and it tends to start after an update rather than out of nowhere. Ask what changed in the days before the errors began.

Where you can reach the admin area, disabling recently updated plugins one at a time identifies it. Where you cannot, renaming the plugins folder over SFTP disables all of them at once, which is blunt but tells you immediately whether a plugin is responsible.

Check four: the built in repair

WordPress includes a repair tool that is switched off by default. Adding a single line to wp-config.php enables a repair page you can then visit, and the official documentation for editing wp-config.php gives the exact line and its placement.

Two things to know. The repair page is unauthenticated while that line is present, so remove the line as soon as you are finished. And repair addresses table level corruption, which is the least likely cause, so reaching for it first is usually reaching past the real problem.

Getting a more specific error

The message on screen is deliberately generic. The server almost always knows more, and two places hold the detail.

The first is your hosting panel’s error log. Most UK hosts expose one, and a database failure normally leaves an entry naming the actual reason: access denied for a user, too many connections, or a server that could not be reached. Those three point at three different fixes, and the on screen message points at none of them.

The second is WordPress debugging. Adding the debug constants to wp-config.php writes errors to a log file inside wp-content rather than displaying them to visitors, which is the important distinction. Never switch on the version that prints errors to the screen on a live site: it exposes file paths and database details to anyone who visits.

The official MySQL error handling reference covers the less common messages, though the six above account for nearly all real cases.

Spending five minutes finding the specific error is almost always faster than working through the generic list, and it is the step most people skip because the site being down feels like a reason to hurry.

When to stop and call the host

Stop if the credentials are confirmed correct, the site is not intermittent, and nothing recently changed. At that point the problem is on the server side and further changes from you can only add variables.

Give the host three things: the exact error, the time it began, and what you have already ruled out. A ticket that says the site is down gets a slower answer than one that says the credentials in wp-config match the panel and the error began at a stated time.

Why restoring a backup comes last

Restoring feels decisive, and it is the step most likely to cause the loss people were afraid of. If the database was healthy and merely unreachable, a restore replaces current content with older content and discards everything since, including orders and enquiries.

If you do restore, take a copy of the current database first, even a database you believe is broken. A broken copy you still hold is worth more than a clean one you no longer have.

What to tell your host

If the checks above point at the server, a precise support request gets a faster answer than “my site is broken”. Include:

• The exact error text and the time you first saw it.
• Whether the admin area shows the same error or a different one.
• What changed in the last day: a plugin update, a migration, a password reset or a traffic spike.
• Whether the built in repair screen ran, and what it reported.
• The database name and user from your configuration file, but never the password.

Then ask two specific questions: did the database server have an incident or maintenance at that time, and did your account hit its connection or resource limit? Those two answers separate a problem on their side from a problem on yours, and they decide whether the next step is waiting or changing something in your own setup. Keep the ticket number. If the error comes back, a pattern across tickets is what persuades a host to move your account to a less crowded server.

Preventing the repeat

Recurrences usually mean one of two things: a site that has outgrown its hosting, or updates applied without anyone checking the result.

The practical fixes are hosting sized for the traffic, updates applied and then verified rather than applied and assumed, monitoring that tells you before a customer does, and backups someone has actually tested restoring. Our guide to WordPress maintenance covers the routine, and what maintenance costs covers what to pay for it.

Our website management and hosting is £20 a month and covers hosting, updates, monitoring and fixes together, which removes the situation where nobody is watching.

If the site is failing in other ways, the white screen problem and a general outage checklist cover the neighbouring symptoms, and our pricing lists everything we do.