Your browser and Uptime Basics do not necessarily reach a website through the same network, DNS resolver, region, or security rules. A website can therefore work for you while a monitoring request fails elsewhere.
Start by checking whether the monitor is currently Down or whether Detailed Logs contain only an individual Down row. One failed check does not automatically create a confirmed outage.
How Uptime Basics confirms Down
For one check cycle to count as a confirmed failure, at least two of three monitoring regions must fail. The monitor changes to Down only after three region-confirmed failed cycles occur consecutively.
This reduces false positives, but it cannot make every monitoring location behave exactly like your device. If the website recovered after the confirmed outage, your browser may work before the dashboard receives and displays the recovery result.
Check the evidence first
- Open the affected monitor.
- Confirm the Last checked time and your dashboard time zone.
- Review Failure Diagnosis for the latest reason and recommended action.
- Open Detailed Logs and inspect the failed rows around the status change.
- Read the Confirmation column to see which regions failed or reached the website.
- Open the incident to review its timeline and diagnostics if a confirmed incident exists.
If the latest log row is Up but the dashboard still shows Down, allow the dashboard's next automatic refresh. A successful availability cycle normally resolves an open outage; the dashboard can take an additional refresh to display it.
Common reasons the results differ
The website recovered between checks
The outage may have been real but brief. Compare your browser test time with the failed-check and recovery timestamps instead of comparing only the current page load.
Firewall, CDN, WAF, or bot protection
A security service can allow your device while rejecting requests from an AWS monitoring region. HTTP 403, 429, repeated timeouts, or regional differences are common clues.
Review the site's firewall, CDN, bot-management, rate-limit, and geographic rules. Allow the monitoring request where appropriate rather than marking a rejection code as successful.
Regional or network routing problem
A hosting provider, transit network, or DNS service can fail in one location while the site remains reachable elsewhere. The Confirmation column shows whether the failure was consistent across regions.
DNS differences
Your device may have a cached DNS answer while a monitoring region receives a different answer or cannot resolve the domain. Check authoritative nameservers, current DNS records, recent DNS changes, and whether all returned addresses serve the website correctly.
The monitored URL behaves differently
Confirm the exact scheme, hostname, path, and redirect chain. For example, https://example.com/health can fail even while https://example.com works.
If redirects are disabled, a redirect response can be treated differently from the final page. If the path requires authentication, configure an appropriate protected-endpoint method or monitor a public health endpoint.
Request method or expected status code
Uptime Basics uses GET by default. If you selected HEAD and the site handles it incorrectly, switch the monitor to GET. HEAD monitors automatically try GET for several common method-related failures when enough timeout remains, but GET is the safer choice for unusual servers.
Responses below HTTP 400 count as successful by default. You can add specific HTTP 400-599 responses as accepted codes when that response genuinely means the application is healthy. Do not accept 401, 403, 404, or 500 merely to hide a configuration or availability problem.
Authentication or custom headers
A protected staging site may require Basic Authentication or a specific request header. Confirm that the monitor has the required configuration. Never put a password, API key, or token in the URL.
Safe troubleshooting order
- Verify the exact monitored URL in a private browser window and from another network if available.
- Compare the browser test with the log timestamps.
- Use Failure Diagnosis to identify HTTP, timeout, DNS, SSL/TLS, or redirect failures.
- Check regional confirmation before changing the monitor.
- Correct the website, firewall, DNS, authentication, or monitor setting responsible for the failure.
- Wait for one successful check cycle and the next dashboard refresh.
Avoid repeatedly pausing, deleting, or recreating the monitor. Doing so can separate the new monitor from the incident and logs needed to diagnose the original problem.
When to contact Support
Contact Support if current checks continue to report Down after the target is confirmed reachable and its access rules are correct. Include the monitor name, monitored URL, approximate timestamps, diagnosis category, and the regions shown in Confirmation.
Do not send passwords, authentication codes, complete authorization headers, or private keys.