A website can fail for one visitor, one network or everyone. Establish the scope before changing hosting or DNS settings. A single failed monitoring location is evidence to investigate, not proof that the entire server is offline or that a particular provider caused the problem.
IN THIS ARTICLE
01 Collect the first evidence
- Record the exact URL, error message and time with timezone. Distinguish a DNS error, connection timeout, certificate warning and application error page.
- Open the site in a private browser window. Test a second normal page rather than relying only on an administrator session or cached homepage.
- Use a second device or independent network where possible, such as mobile data. Check whether other websites work on the original connection.
- Review any existing website monitor and public service notices. Compare the same hostname and protocol from multiple locations.
- If you control the hosting account, check service status, recent changes and the relevant application logs. A working control panel does not prove that the website application is healthy.
02 Interpret the pattern
If only one device fails, review browser state, local DNS caching and security software. If one network fails, consider routing, local resolver results or an access block. If many independent checks fail in the same way, investigate the shared dependency such as DNS, certificate, hosting or application.
A CDN can return cached content while the origin fails, or block a monitoring bot while real visitors succeed. Compare the response you receive with the intended customer journey, including forms or checkout when relevant.
03 Example: turn an outage report into the next useful check
| Observed pattern | Next useful check |
|---|---|
| The office connection fails, but the same URL works on mobile data. | Compare the office resolver, network route and any access block. Record both results before changing the website. |
| The homepage opens, but checkout returns an application error. | Record the failing checkout URL and inspect the relevant application logs and recent changes. |
| Several independent networks show the same certificate warning. | Check the certificate presented for that exact hostname and the path through any CDN or proxy. |
These patterns guide the investigation. They do not prove a cause by themselves. Keep the time, full hostname, protocol and error together so later checks can be compared fairly.
What should I change first?
Change the component supported by the evidence. Do not replace nameservers because a PHP page returns an error, or restore an entire account because one browser has an old redirect. Keep a record of the original setting before any repair.
04 Escalate with a useful report
Send support the URL, timestamps, affected networks, exact error and recent changes. Include a redacted screenshot or log excerpt. This gives the team a starting point and helps distinguish an infrastructure incident from a local or application-specific fault.