Start with the action that failed. “The homepage responds” and “I can complete my booking” are different claims. Record both if they disagree.
1. Keep the original failure visible
Before refreshing, note the exact address, the action you tried and the error message. Record the time with its time zone. If a payment or submission timed out, check whether it completed before retrying; an error screen does not prove that nothing was processed.
Open the same page once in another browser session. If an authenticated page fails, a private window that only shows the sign-in page is not an equivalent test. Compare the same step with the same permissions. Avoid clearing all browser data at the beginning: doing so can remove useful evidence and require a new sign-in without identifying the cause.
2. Compare the browser failure with the host check
Run the domain through the website checker. WebsiteDown requests the origin, follows redirects and displays regional HTTP results. It does not test a path such as /checkout or sign in to your account. The measurement methodology documents the exact scope.
| What you see | What to investigate next |
|---|---|
| Browser fails; checker receives 200 | Identify whether the browser fails at login, a particular page or a background request. A root-page response has not tested those actions. |
| Browser works; checker receives 403 or times out | Compare request methods and automated-traffic policy. Keep the user-visible success in the report; do not declare a global outage. |
| Both receive server errors | Capture the failing hostname, status and timestamp. Compare them with the provider’s status page or, for your own site, server logs. |
| Some regional checks fail | Record which ones and their timestamps. Compare a second network; a regional failure does not demonstrate a problem with the visitor’s own device. |
3. Change one variable at a time
On a device you control, compare Wi-Fi with mobile data. If your workplace requires a VPN or managed network, follow that policy. Do not switch off protections just to make a test pass. Record the network difference instead. If all sites fail, test the local connection first; if only one service fails, keep investigating that service and the path to it.
For example, suppose the same signed-in page fails on office Wi-Fi and succeeds on mobile data. That narrows the investigation to differences between those attempts. It does not prove that office DNS is wrong: filtering, address-family selection and provider rules could also differ. The next useful evidence is the browser error or failing HTTP request.
4. Check the exact URL if you own or support the site
Use a public, read-only URL. This request performs GET, prints response headers, follows redirects and discards the body:
curl --location --max-redirs 5 --max-time 20 --silent --show-error \
--dump-header - --output /dev/null 'https://example.com/'Replace the example with the failing public page. Multiple header blocks indicate redirects; read the last response as well as the chain. Do not paste authentication cookies, private URLs or signed links into public checkers. A curl request is not a browser test: it does not render the application or automatically reproduce its logged-in session.
A status code describes how a particular request was handled. For example, 403 means the request was refused, while 503 indicates that the server could not handle it at that time. Neither identifies the root cause by itself. See HTTP response semantics.
5. Compare with an actual provider update
Open the provider’s status page if it has one. Check the affected component, region and incident timestamp. A current incident about video uploads does not necessarily explain a sign-in problem. A green dashboard is useful context, but an incident can be reported before the provider posts an update.
Preserve the provider link and the scope of its statement. A service homepage, support article or social profile is not itself confirmation of an outage. On WebsiteDown service pages, use the linked resource for what it actually provides.
6. Send evidence someone can act on
Observed at (include time zone):
Service and hostname:
Action that failed:
Exact browser error / HTTP status:
Affected page (remove private parameters):
Network and device:
Second network or session result:
WebsiteDown target, verdict and available region count:
Provider incident URL, if relevant:
Last successful attempt, if known:Download the checker’s JSON to preserve its original timestamps. A shared check URL starts or displays another check and is not an immutable copy of the original result. Keep screenshots of the error if they help, with personal details removed.
When to stop troubleshooting locally
If a matching provider incident explains the failed action, follow its updates and avoid repeating disruptive resets. If the evidence instead points to one account, send it to account support. If you own the service, compare the exact failure window with application and infrastructure telemetry before changing DNS, redeploying or rolling back. Those are different interventions and each needs its own evidence.
For unresolved name errors, continue with the DNS diagnosis. If the browser and checker disagree, use the response interpretation guide.