Your site is not loading, and every minute it stays that way feels expensive. Enquiries are not coming in, or customers are messaging to ask whether you are still open. This page is about that moment: how to tell what kind of “down” you are looking at, what is worth checking before you call anyone, and what happens when you send the problem to us.
If you are not yet sure what the error on your screen means, our guide to common WordPress errors groups them by type with a short explanation of each. If you already know you need someone on it now, read on.
What “down” can actually mean
Owners use the word for several different situations, and each one points somewhere else. It helps to know which you have before anyone starts changing things.
The browser cannot reach the server at all
You see a browser message such as “This site can’t be reached”, “DNS_PROBE_FINISHED_NXDOMAIN” or a connection timeout. WordPress has not even been asked for the page. The cause is usually outside the site: an expired domain, DNS records that were changed, a hosting account that was suspended or not renewed, or a server that has stopped. These are fixed at the domain registrar or the host, not inside WordPress.
The server answers with an error code
A plain page with “500 Internal Server Error”, “503 Service Unavailable” or “504 Gateway Timeout” means the server is there but something behind it failed. Sometimes that is WordPress code, sometimes the hosting stack is overloaded. Our explanation of the 502, 503 and 504 status codes is useful here, and a persistent 500 has its own repair page for 500 errors.
WordPress answers, but with a failure message
Messages like “There has been a critical error on this website” or “Error establishing a database connection” come from WordPress itself. The first is almost always a plugin or theme crashing; the second means the database is unreachable. Both have dedicated pages: recovering from the critical error and repairing a lost database connection.
The site loads, but not for everyone
It works for you but not for a customer, or only on Wi-Fi, or only in one country. That points to DNS that has not finished updating after a change, a firewall blocking certain addresses, or a cache serving an old broken copy. These are real problems, but they are not the same as a site that is down for everyone.
It is not a fault at all
If the site loads but sends visitors to a different website, shows pages you never wrote, or your browser shows a red security warning, treat it as a possible compromise. Rolling back plugins will not help. Go straight to our emergency help for hacked sites, which is a separate process because the first job there is containing the damage.
Checks to make before you message anyone
Ten minutes of careful looking usually narrows the problem a lot, and nothing here touches the server.
- Try it from your phone on mobile data. If the site opens there, the issue may be your office network, your browser or a DNS change still spreading.
- Load a second page, and wp-admin. If the home page fails but
/wp-admin/loads, or the reverse, that tells whoever fixes it a great deal. - Log in to your hosting control panel. Look for notices about suspension, unpaid invoices, disk space being full or resource limits being hit. Hosts often put the answer in a banner there.
- Check that the domain is still yours. Your registrar account shows the expiry date. An expired domain takes the whole site and its email with it.
- Look in the admin inbox. WordPress may have sent an email about a fatal error with a recovery mode link, and your host may have sent one about the account.
- Think back over the last day. An update you clicked, a plugin you installed, a change your developer made, a PHP setting your host switched. The cause is very often the most recent change.
What to avoid: restoring a backup straight over a live store without checking which orders came in since, deleting the whole plugins folder rather than renaming it, or asking several people to work on the site at the same time. Each of these can turn a short outage into a long one.
What to send us
The more precise the first message, the sooner the real work starts. On WhatsApp or through our contact form, send:
- The site address, typed out in full.
- A full-screen screenshot with the web address visible, or the error message copied word for word.
- When you first noticed it, and whether it is down for everyone or only some people.
- Anything that changed recently, even if it seems unrelated.
- Who hosts the site, and whether you can log in to the hosting panel, the WordPress admin and the domain registrar.
Do not send passwords in the first message. Once we have looked and agreed to go ahead, we will ask for the access we need, and we can suggest creating separate logins for us that you remove afterwards. Our short guide on describing a website problem to a developer has more on what makes a report useful.
What we do first
Our first job is to look, not to start changing things. We open the site, read whatever error it shows, and check the server and WordPress logs if we have access (our post on reading the WordPress error log shows what those look like). Then we tell you honestly what we see, what we think the cause is, and when we can start on it. If the problem is with your host or domain rather than WordPress, we say so, because no amount of work on the site will fix an expired domain.
Before any change, we take a backup of the files and the database as they are, broken state included. That sounds odd, but it means nothing is lost if a fix goes wrong, and the broken copy is often useful for finding the cause later.
Next comes getting the site serving pages again. Sometimes that is the whole fix, such as rolling back a plugin update that caused a fatal error. Sometimes it is a temporary measure, like pausing a failing plugin so the rest of the site returns, followed by a proper repair. When we use a stopgap, we tell you what it is and what it leaves unfinished. Where the fault allows, the proper repair happens on a staging copy so the live site is not used for experiments.
We handle an outage, or a shop whose checkout has stopped, as an urgent job. What we will not do is promise a fix time before we have seen the cause, because a crashed plugin and a corrupted database are very different amounts of work.
After the site is back
Getting pages to load is not the end of it. We check the parts that matter to your business: the contact form sends, the checkout completes, logins work, and the pages that bring in traffic display properly. Then we write up in plain language what failed, why, and what we changed.
The write-up should also say whether this is likely to happen again. An outage caused by a one-off bad update is different from one caused by a hosting plan that is too small, a plugin whose developer has stopped updating it, or a PHP version the theme was never built for. If the cause is structural, we tell you, and what it would take to deal with it.
Two things reduce the chance of the next emergency. The first is knowing when the site goes down rather than hearing it from a customer; website uptime monitoring explains how that works. The second is regular, careful updates with a backup before each batch, which is what our maintenance plans are for.
Emergency help or the regular bug fixing service?
This page is for a site that is down now. If the site is up but something on it is broken, a form, a layout, a slow page, our WordPress bug fixing service is the better fit and works the same way: you send the problem, we look and tell you what we see. If you are not sure which you need, just send the error. Working out which kind of problem it is is part of the job.
For sites outside India, the team works in IST, which sometimes means a fix happens during your night. Payment from abroad is by PayPal or Wise.