Your website is unreachable mid-trading day. Before changing a setting or calling anyone, run this sequence: confirm the site is really down, read the exact error, check the externals, match the failure to the last change, and roll back before fixing forward. Guessing destroys the evidence the fixer needs.
The short answer: confirm, classify, check the externals, check what changed — in that order
Work through five steps, stopping when one answers the problem. Confirm the site is down for everyone. Record the exact error. Check the externals: host status, domain and certificate expiry. Ask what changed last, matched to when the site broke. If a change caused it, undo it rather than layering on fixes. If nothing explains it, escalate with the evidence pack.
Step 1 — Is it down for everyone, or just you? (second device, mobile data, a downtime checker)
Rule out your connection first. Open the site on a phone using mobile data with Wi-Fi off, and ask a colleague elsewhere to try it. Then run the address through a free downtime checker, which loads it from servers elsewhere.
If it loads everywhere except your office, the website is not down: the problem is your network or cache — clear the cache next. If every check fails, the outage is real. Note the time; that timestamp anchors later steps.
Step 2 — Read the exact error and write it down (what 500, 502, 503, "not private" and "server not found" each point to)
The error on screen is your most useful clue. Screenshot it exactly, including any code. In plain language, common messages point in different directions:
| What you see | What it means | Where it points |
|---|---|---|
| 500 Internal Server Error | The server met an unexpected condition it could not handle (MDN) | Your site's code or server configuration |
| 502 Bad Gateway | A gateway or proxy received an invalid response from the server behind it (MDN) | The link between the front server and your site |
| 503 Service Unavailable | The server is not ready to handle requests, often maintenance or overload (MDN) | Hosting capacity or planned maintenance |
| "Your connection is not private" | The browser cannot trust the site's certificate, often because it has expired | The certificate class — see Step 3 |
| "Server not found" or DNS error | The browser cannot translate your domain name into a server address | Domain, DNS records or an expired domain |
Treat the certificate warning as classification only: note it, check expiry in Step 3, escalate the repair. Our guide to HTTPS problems, mixed content and expired certificates owns that fix.
Step 3 — Check the externals that are not your website: host status, domain expiry, certificate expiry
Some outages have nothing to do with your website's files. Check your host's status page first: if an incident is reported, monitor it and tell customers; do not touch your site. Next, confirm your domain has not expired and renewal succeeded; an expired domain produces the server-not-found error above.
Then check the certificate expiry from the browser's padlock or warning icon. If it expired today, you have found the cause. Check any content delivery network or firewall in front of the site, whose status page can show an incident even when your host is healthy. If you do not know who holds these accounts, our website handover and ownership checklist lists the access to hold before an incident, not during one.
Step 4 — What changed last? Updates, plugins, edits and traffic spikes, matched to the time it broke
If the externals are clear, ask the most diagnostic question: what changed last? List anything in the hours before the failure — a core, theme or plugin update, a new plugin, an edited page or setting, a tool connected, or a campaign sending a visitor spike.
Match each change to when the site broke. Failing minutes after a plugin update names a likely cause; failing as a promotion launched points to capacity. Write the timeline down even if it feels obvious: it lets a developer skip hours of guessing.
Step 5 — Roll back before you debug forward: restoring the last known-good state safely
When a change lines up with the failure, undo it before trying anything new. Deactivate the plugin just updated or installed, revert the edit, or restore the backup taken just before it if your host offers one-click restore. Reverse one thing at a time, checking after each.
Rolling back is not restoring an old backup in a panic. Restore a full backup only once you know when the site last worked, accepting later orders or enquiries may need reconciling. If a rollback brings the site back, leave it and report the culprit rather than reapplying the update in trading hours. Prevention such as a proper website backup and disaster recovery plan belongs after the incident.
While it is down: what to tell customers and how to keep enquiries coming in (phone / WhatsApp)
Silence loses more business than downtime does. Post a short, honest note on your social profiles and Google Business Profile: the site is temporarily unavailable, you are working on it, and customers can still reach you by phone and WhatsApp — where most UAE enquiries arrive.
Promise no restoration time you cannot control. Ask staff to log enquiries that would normally come through the site, so you can measure the cost and follow up. If the outage will run for hours, ask whether a holding page with your contact details can be shown at the domain.
The evidence pack: the five things to have ready before you call your host or developer
Give whoever you call these five things first, and the fix starts immediately. One, the exact error: screenshot and precise wording or code. Two, the scope: down for everyone, confirmed on a second network and a checker, or only for you. Three, the timeline: when it last worked, when it broke, what changed in between. Four, the externals checked: host status, domain and certificate expiry. Five, access details: host, registrar and admin logins, ready to share safely.
Send it to the right party first: a host incident to the host, a plugin-update error to whoever maintains the site. If the failing layer is unclear, start with the host, whose logs can rule the server in or out.
When to stop: the red flags that mean escalate now (suspected hack, data loss, payment pages down)
Stop and escalate immediately if the site redirects visitors elsewhere, shows pages you never created, or the browser warns it may be hacked: that is a suspected compromise, and our guide to hacked WordPress site recovery steps applies, not this one. The same applies if content, orders or records are missing or altered, if payment pages fail, or if the host suspended the account. Preserve screenshots and get a specialist involved.
A site that loads but is simply slow is a different problem: use our owner diagnosis for a slow website instead.
Common mistakes (changing settings at random; restoring a backup before diagnosing; calling the wrong party first)
Three mistakes reliably lengthen outages. Changing settings at random alters the evidence, so nobody can tell what broke or fixed it. Restoring a backup before diagnosing can overwrite logs needed to find the cause, and restore the same fault. Calling the wrong party first loses an hour: your designer cannot fix a hosting outage, and your host will not debug a plugin conflict. Classify first, then call once, evidence pack ready.
FAQ
How do I check if my website is down for everyone or just me?
Try a second device on mobile data with Wi-Fi off, ask someone elsewhere to open it, and run the address through a downtime checker. If it loads elsewhere, the fault is local. If every check fails, the outage is real.
What does a 500 error mean in plain language?
A 500 Internal Server Error means the server met an unexpected condition it could not handle, in MDN's words. It is a general server-side fault, often in site code or configuration. Record the message and time, check what changed last, and pass both to your host or developer.
What is the difference between a 502 and a 503 error?
A 502 Bad Gateway means a gateway or proxy received an invalid response from the server behind it. A 503 Service Unavailable means the server itself is not ready, commonly due to maintenance or overload. A 503 is often temporary; a persistent 502 needs host investigation.
My site says "your connection is not private". Is it hacked?
Usually not. That warning most often means the browser cannot trust the certificate, commonly because it has expired. Note the expiry date in the browser and escalate the renewal. Treat it as a certificate fault, not a compromise, unless you also see redirects or pages you never created.
Should I restore a backup as soon as my website goes down?
No. Diagnose first. Restoring before you know when the site last worked can overwrite evidence and recent orders, and restore the same fault. Roll back only the change that matches the failure, or the backup taken just before it, once the timeline is clear.
Still down after the sequence? Get a developer to take it from the evidence (CTA)
If the site is still down after this sequence, you have done the part only you can do. Hand the evidence pack to a developer and let them work from it, not from zero. WebStackRank's web development consulting is built for this moment, backed by our core web development services and the website development process. Send the five items and your trading hours, or reach us via our website development company in Dubai page.
