Two monitoring services can report different results without either result being fabricated. They may test different locations, times, URLs, methods, timeouts, DNS answers, redirect behavior, or definitions of success.
Compare the exact test conditions and your own server-side evidence before deciding which result represents customer availability.
The main comparison dimensions are region, timestamp, URL, request method, timeout, redirect policy, accepted status codes, headers and authentication, DNS answer, confirmation policy, and browser execution.
Why results differ
| Difference | Possible effect |
|---|---|
| Monitoring location | Regional routing, CDN edge, firewall, DNS, or provider failures affect one location but not another |
| Check timestamp | A brief outage can occur between the services' scheduled checks |
| Exact URL | A homepage can work while a login, API, redirect target, or path fails |
| GET versus HEAD | Some servers accept GET but reject or mishandle HEAD |
| Timeout | A slow response can pass a longer timeout and fail a shorter one |
| Redirect policy | One service may follow the redirect while another evaluates the first response |
| Accepted status codes | One service may count a configured 401, 403, or 404 as healthy |
| Headers or authentication | An allowlisted endpoint may accept one configured monitor and reject another |
| DNS resolver and cache | Different resolvers can temporarily receive different answers |
| Outage confirmation | One provider may alert on one failure while another requires multiple checks or regions |
| Browser execution | A browser can run JavaScript, retain cookies, and complete challenges that an HTTP monitor cannot |
Uptime Basics availability checks evaluate the HTTP result. They do not execute JavaScript, solve CAPTCHAs, maintain browser cookies, or inspect the page for expected text.
How Uptime Basics evaluates regional failures
The normal scheduled check uses the primary monitoring region. If it fails, two additional regions can run the same availability settings.
At least two of the three regions must report failure for that cycle to count as region-confirmed. Three consecutive region-confirmed failed cycles are required before the monitor becomes Down.
An unavailable confirmation probe is not automatically counted as a website failure. If the primary request fails but the available regional evidence does not confirm it, Detailed Logs preserve the difference without opening a confirmed outage from that cycle.
Compare results step by step
- Record the timestamps from both services, including each displayed time zone.
- Confirm both services monitor the exact same URL and path.
- Compare GET or HEAD, timeout, interval, redirect behavior, accepted status codes, custom headers, and authentication.
- In Uptime Basics, open Detailed Logs and review Status, HTTP, Latency, Diagnosis, Error, and Confirmation.
- Open the related incident when Uptime Basics reached a confirmed Down state.
- Compare DNS, CDN, WAF, load-balancer, proxy, web-server, and application logs for those same timestamps.
- Check the provider's official status page for a declared incident, while remembering that it may describe a broader service rather than your exact URL.
- Test from another real network only as supporting evidence, not as a replacement for external monitoring.
Use UTC timestamps when sharing data between systems. This avoids comparing events that only appear different because one interface uses a local time zone.
Interpret common patterns
Your browser works, but monitoring fails
Your browser may use cached DNS, an existing session, a different network route, or a security rule that trusts residential traffic. Check the exact URL in a private session and compare server logs.
A successful browser request proves that one user path worked at that moment. It does not prove every monitoring region or customer route was healthy.
One Uptime Basics region fails
One regional failure can indicate a route, edge, resolver, or security-policy difference. The cycle is not region-confirmed unless a second region also fails.
Review whether customers in the affected location should be able to use the service. A regional failure is not automatically a false positive.
Two or three regions fail
Matching failures from multiple regions are stronger evidence of a broad availability or access problem. Look for shared DNS, origin, certificate, deployment, capacity, CDN, or security-policy causes.
Another monitor reports Down first
The other provider may check more frequently, may have checked just after the outage began, or may alert after fewer failures. Uptime Basics waits for regional and consecutive confirmation to reduce false outage alerts.
Detection speed and false-positive resistance are a tradeoff. Compare the first failed request timestamp, not only the alert time.
An official status page says everything is operational
An official page may describe an entire provider, product, or region and may be updated after investigation. Your exact endpoint, account, DNS, integration, or route can still fail.
Use the official page as one source of context. Independent monitoring answers whether the selected public URL was reachable under its configured test conditions.
Decide whether to change the monitor
Change the monitor only when the new setting matches the availability you actually want to measure.
- Use the canonical URL rather than a redirect chain when possible.
- Use GET when the website does not support HEAD consistently.
- Increase the timeout only when the normal healthy response legitimately needs it.
- Accept an additional HTTP code only when that exact response is a documented healthy result.
- Configure a dedicated header or Basic Authentication for an authorized protected endpoint.
- Create a lightweight health endpoint when normal webpages depend on browser-only behavior.
Do not accept errors or disable security controls solely to make a graph look healthy.
When to contact Support
Contact Support when equivalent settings repeatedly produce unexplained differences or Uptime Basics shows regional evidence that conflicts with your server logs.
Include the monitor name, exact URL, UTC timestamps, displayed diagnosis, regional Confirmation summary, other service's sanitized result, and relevant server-log summary. Never send passwords, request-header values, cookies, private keys, verification codes, or complete security configurations.