Your Website Is Down: A Calm Troubleshooting Checklist
Website down? A calm checklist — confirm it with a website down checker, work out why, and fix it without making the outage worse.
By Matthew Zhao · Editor, Hosted EZ
When your website is down, start with the question that decides everything else: is my website down for everyone, or just for me? A website down checker answers that in ten seconds. From there, this checklist works through the likely causes in order — DNS, domain expiry, server, application — without the panicked changes that make an outage worse.
This guide focuses on the checks a small-site owner can make safely. It also points out where a host, registrar, email provider, or developer needs to take over. Read how to choose a web host if you need the broader setup, and our migration guide before changing live infrastructure.
First, confirm the website is down for everyone
Run the URL through a website down checker, or ask someone on a different network to load it. If the site works for them, the problem is your DNS cache, your network, or your browser — a much cheaper fix than an outage.
If it is down for everyone, record the exact status code, URL, time, and whether the issue affects all visitors or only logged-in ones. Those details narrow a support ticket much faster than a description such as "the site is broken."
Why is my website down? Check in this order
Check recent changes, resource usage, and logs before restoring random files. A timeout, a full disk, a bad deployment, an expired domain, and a DNS problem can all look similar from a browser. If you have a specific status code, our guides to the 500 internal server error and the 503 service unavailable error go straight to those causes.
Use a private browser window or a separate device after a change. That removes some of the confusion caused by cookies and cached redirects. If a DNS record is involved, note the TTL and allow the old answer time to expire before assuming the change failed.
Test the result like a visitor
Make the smallest safe correction, then test again from a fresh browser session. If it does not change the symptom, revert it and move to the next theory. Keeping that discipline prevents a second problem from hiding the first.
Test the normal path first, then the part that has the most consequence. For a store, that is checkout. For a form, it is receiving the email. A test should answer one question rather than produce a vague impression.
When to stop and ask for help
Stop when the next action could overwrite data, change production mail, or remove access to the account. Send support the domain, time in UTC, exact error, and the changes you made. Include a screenshot when it shows the error, but do not include private keys, passwords, or full payment information.
MDN's HTTP status reference has useful background on what each error code actually means: MDN's HTTP status reference. Use it to understand the terms, then return to the small, reversible next step.
A sensible maintenance habit
Put the final configuration and the result in a short maintenance note. Outages repeat because nobody remembers which account owns a record or which plugin was disabled last time. A dated note turns the next incident into a lookup instead of an investigation.
Keep the change auditable
Use a short before-and-after record. Write the setting you found, its old value, the exact time you changed it, and the result of the test. If the change has a delay, such as a DNS TTL or a cache expiry, write the time you expect the new answer to be visible. This record is useful even when everything works. A few months later, it tells you why a setting has an unusual value.
Do not confuse an account dashboard with evidence from the live site. A dashboard can show that it accepted a record or a deployment. The visitor still needs to receive the page, email, redirect, or certificate you intended. Test from outside the account, and use a second connection if a cached answer could mislead you.
If you hand the task to someone else, give them the record rather than a conclusion. "The site is broken" is hard to investigate. "The outage began after this update, affects this URL, and persists in a private window" gives the next person a useful starting point.
One last check
Before you close the ticket or move to the next task, load the site the way a visitor would, not only through the account dashboard. If the result is different, note the difference and keep troubleshooting from that point. A quiet confirmation now is much easier than discovering the site is still down from a customer email.
Leave a useful handoff
Save the final test result with the date and account involved. If someone else needs to revisit the outage, they should be able to see what changed without reconstructing the whole incident from browser history.
Bottom line
A website down incident gets shorter when you confirm the outage is real, work through causes in order of likelihood, and make one reversible change at a time. Keep evidence, protect your backups, and ask support before a safe troubleshooting step turns into a data-loss risk.
Frequently asked questions
Should I change everything at once to get the site back up?
No. Change one related setting, test it, and keep the previous value until you know the result is stable.
What should I give hosting support when my website is down?
Give the domain, exact URL or service, UTC time, error text, and steps already tried. That is usually enough for support to find the relevant logs.
Should I keep a backup before making fixes?
Yes. Download or verify a recent backup before edits that affect files, databases, email, DNS, or software versions.
About the author
Matthew Zhao
Matthew has spent his career running production server fleets — tens of thousands of machines' worth. He writes about hosting the way he wishes someone had explained it to him: plainly.
About Hosted EZ →Get the next guide in your inbox
One email when we publish something worth your time. No spam, unsubscribe whenever.
