If you are asking what to do when your website is down, start by confirming the problem and recording what you see. Do not rush to change settings or remove anything. A failed page can come from several places, and the same error on your screen does not tell you which one is responsible.
Website downtime here means your site is unreachable or an important function fails for the people trying to use it. First response is the period between noticing the problem and handing the investigation to whoever maintains the site. This checklist covers that period, not DNS or server changes.
Key Takeaways
- Confirm the problem on a second device or network before treating it as a site-wide outage.
- Record the exact page, error message, time and time zone.
- Check official notices from your hosting, domain or other provider, then share your evidence with the site maintainer.
- Avoid hurried changes to DNS, server settings, files, plugins or backups. Escalate first if you are not responsible for the site.
1. Confirm the website is actually unavailable
Try the affected address from another device and a different connection. Use a phone on mobile data instead of the same office Wi-Fi, and ask someone outside your workplace to check if you can. This helps separate a problem on one device or network from one affecting other visitors.
Use the exact page that failed, not just the homepage. If the homepage loads but a booking, product or contact page does not, that difference matters. Try once more after a short pause in case the failure was temporary. Avoid repeated refreshing, and do not use random online tools that ask for account access.
A page loading for you does not prove it works for every visitor. A failure on one connection does not prove the whole site is offline. Treat each check as evidence about scope, not a final diagnosis. For ongoing checks and alerts, see our guide to website uptime monitoring for small businesses. Monitoring surfaces selected symptoms; it does not prevent every outage or identify every cause.
2. Capture the error and the time
Before closing the tab, take a screenshot and note the full URL, the date and time, and your time zone. Copy the exact error text if you can select it. Record whether the page showed a blank screen, a browser message, a security warning, a host-branded notice or an application error. Keep passwords, customer details and payment information out of the screenshot.
Also record what worked. Did the homepage load? Did other pages fail? Which device and network did you use, and did the issue repeat on a second connection? This gives your host or maintainer something specific to investigate. “The website is broken” leaves too many questions open; an exact error, URL and timestamp can be compared with provider notices and support logs.
3. Check official provider updates
Check the status page and account notifications for the companies that may be involved. These can include your web host, domain registrar, DNS provider, content delivery provider or website platform. Use a saved bookmark, a link from the provider’s official website, or sign in through your usual route.
A public status page can report a provider incident. No notice does not prove the provider is clear or that your own site is healthy. For example, Cloudflare’s official status page reports the status of its services, and it notes that each incident may affect only specific Cloudflare products or regions rather than all services globally. If Cloudflare is not part of your setup, that page will not diagnose your site.
The same limit applies to cloud platform status pages. The AWS Health Dashboard shows publicly reported service events across AWS Regions, and AWS states that this view covers public events only, while events specific to an individual account are visible after signing in (AWS Health Dashboard documentation, retrieved 22 October 2026). The practical lesson is the same for any provider: an official status page is a reliable source for what the provider has announced, and not a diagnosis of your site.
Do not treat an outage map or social media post as confirmation that your particular website is affected. Community reports can be clues, but they may describe another service, region or problem. Share a relevant provider notice with your maintainer and let them confirm whether it matches your setup.
4. Work out how much of the site is affected
Scope here means the pages and functions affected, not the underlying technical cause. Check the homepage and a few important pages, such as a product, booking or contact page. Note whether the problem affects the whole site, one section or one function. Do not submit test enquiries while the site is unstable; if you later need to verify delivery, follow a controlled process such as our guide to checking whether a website contact form is working.
| What you observe | What to record |
|---|---|
| One page fails | The page address and whether related pages behave differently |
| Several pages fail the same way | The shared error, affected addresses, and whether the homepage is included |
| The site loads but a feature does not | The feature, what you clicked, and where it failed |
| Only one person or network sees the issue | That detail, so it is not mistaken for a site-wide outage |
This is a scope check, not a technical diagnosis. Avoid logging into systems you do not manage or trying changes just to see what happens.
5. Contact your host or site maintainer
Once you have the evidence, contact the person or provider responsible for the site. Use your established support channel or emergency contact if you have one. Include the website address, affected pages, exact error, time and time zone, devices and networks tested, what still works, and any matching provider notice. Say whether customers currently cannot use an important function, such as placing an order.
A useful first message is short and specific:
Our website appears to be unavailable. At [time and time zone] on [date], [URL] showed [exact error]. I checked from [device and network] and a colleague on a different network saw [result]. The homepage [did/did not] load. [Provider] has [or has not] posted a status update. Could you confirm receipt and tell us who is investigating?
Ask who is investigating and when to expect the next update. If several providers could be involved, start with your site maintainer or host and ask them to coordinate. Keep a simple incident timeline by adding observations and replies with their times. If you cannot remember who maintains the site, check business records for the original web developer, hosting invoices, domain renewal notices or support emails. Do not send login credentials by email or post them in a public support forum.
Provider support guidance supports this approach. AWS, for example, asks customers to describe who is affected, what happened and its impact, when it began including the time zone, which resources and region are involved, and what has already been tried (AWS Support case guidance, retrieved 22 October 2026). It also advises checking the relevant health dashboard before opening a case and notes that incident information may appear there with a slight delay. Those are specific to AWS support, not a universal template, but they show why a short, factual report with times and scope helps a provider investigate.
6. Avoid risky changes while you are under pressure
Do not edit DNS records, server configuration or website files. Do not disable plugins, delete content, or attempt a rollback unless the person responsible for the site has assessed the situation and given you a clear plan. These actions can change the evidence, affect other parts of the site or make recovery harder. If you are not the technical owner, document and escalate rather than experiment.
Be cautious with unsolicited messages claiming they can restore the website immediately. Confirm the sender through a known provider channel before granting access or paying an invoice. A genuine support request should not require a password in a public post or an unverified message.
After the incident, ask the maintainer to explain the confirmed cause, what was done, whether any orders or enquiries need follow-up, and what should be reviewed. The aim is to understand the incident, not to make an emergency change without context.
When the site is back, review the response
When pages load again, confirm the important customer journeys with your maintainer. A homepage loading again does not confirm that every form, booking flow or checkout is working.
For routine checks, alerts and responsibility, use our small-business website monitoring guide. That guide covers ongoing monitoring; this checklist is for the first response to a suspected outage. If the site runs WordPress and you are reviewing ongoing update and security responsibilities after the incident, see our WordPress maintenance and security guide. If you are considering ongoing support, review our website maintenance services and maintenance packages to see what each covers. Monitoring and uptime commitments depend on the hosting arrangement and plan. DreamoonTech’s stated 24/7 monitoring and 99.9% uptime guarantee apply only to websites hosted by DreamoonTech, not every third-party-hosted site.
Keep the incident notes with your website records. If a similar issue happens again, the earlier timeline can help you describe what changed. If your concern is instead that a functioning site receives visits but few enquiries, that is a different question; see our guide to diagnosing website traffic without leads.
Frequently Asked Questions
Why is my website down?
There are several possible causes, including a problem with the site, its hosting, or another provider in its delivery path. A browser error alone does not identify which one applies. Record the exact message, check from another device or network, look for official provider notices, and send those details to your host or site maintainer.
How can I tell whether my website is down for everyone?
Try the same URL on a separate device using a different network, and ask another person to check. These checks can show whether the problem is limited to one device or connection. They cannot prove that every visitor is affected. Share the results with the person responsible for the site.
Should I change DNS or restore a backup if my site is down?
Not as an initial response. DNS and backup changes can affect the site and should be assessed by the host or site maintainer, who can check the circumstances and the available recovery plan. Capture the symptoms and contact them before making changes.
What information should I send to website support?
Send the affected URL, exact error text or screenshot, time and time zone, device and network used, whether other pages work, and any relevant provider status notice. Do not include passwords, payment details or customer information. Use the provider’s approved secure support channel.
Conclusion
When a website appears to be down, confirm the issue from another device or network, capture the exact error and time, check official provider updates, and list what is affected. Then contact your host or site maintainer with that evidence. Avoid risky technical changes until the person responsible has assessed the situation.
This measured response helps the right person investigate without adding avoidable uncertainty. Once service returns, confirm important pages and functions, and keep the incident record for next time. If you want help planning who should respond to site issues, contact the DreamoonTech team.