To compare like with like, test the exact same URL with the same request type, timeout, and check interval from each network at the same time. Then compare the same result metric, such as success rate or response time, over the same period. A website availability test is an automated request that checks whether a page or service responds correctly. Differences between networks are normal, so a fair comparison controls the test setup before judging the site.
Table of Contents
- Why does the same site look up in one place and down in another?
- What should you lock down before you compare results?
- How do you read timeouts, DNS errors, and HTTP statuses?
- How do you set up a fair check for WordPress or Drupal?
- When should you act on a single-network failure?
- Frequently Asked Questions
Why does the same site look up in one place and down in another?
A passing check in one office and a failure on mobile data does not always mean the site is down. The request may take a different route, use a different domain-name resolver, hit a different content-delivery edge, or face different filtering.
Caching also changes results. One network may receive a cached copy from a nearby server, while another must reach the origin server. IPv4 and IPv6 paths can differ too, especially for WordPress or Drupal sites behind mixed network setups.
What should you lock down before you compare results?
Use the same target everywhere: protocol, domain, path, query string, HTTP method, headers, and redirect handling. A homepage check, a login-page check, and an API check measure different things, so do not mix them.
Match timing and judgment rules as well. That means the same timeout, retry rule, check frequency, measurement window, and definition of success.
- Same URL, including http versus https and www versus non-www
- Same request type, headers, cookies, and user agent
- Same timeout, such as 10 seconds, with no extra retries on one network
- Same interval and window, such as every minute for 30 minutes
- Same pass rule, such as HTTP 200 with expected text on the page
How do you read timeouts, DNS errors, and HTTP statuses?
Group failures by cause before comparing networks. A DNS error means the name was not resolved. A connection timeout means no server answered in time.
An HTTP 500-range status means the server answered but reported an internal problem. Application logins need extra care. A 200 status with a maintenance page, captcha page, or redirect to an error page is not real availability. Check for expected content, such as a key heading or cart marker, rather than status alone.
How do you set up a fair check for WordPress or Drupal?
Test both the cached front end and one uncached origin path. Front-end checks show visitor experience, while an uncached health endpoint can reveal origin trouble during traffic spikes, plugin updates, or cron runs.
Keep forms, carts, and payment steps separate from simple availability checks. Those flows need scripted transaction monitoring with test accounts and careful handling of personal data. For basic availability, use anonymous page and endpoint checks across home, office, mobile, and each monitoring location.
When should you act on a single-network failure?
Act when the failing network matters to visitors or revenue, even if other networks pass. A regional ISP outage, blocked IP range, expired allowlist entry, or misdirected geographic rule can affect real users while global monitors stay green.
Log the network name, connection type, IP version, resolver, timestamp, target URL, status code, timing, and traceroute or error text. That record helps hosting support, CDN support, or a site developer reproduce the path and fix routing, firewall, DNS, or certificate scope.
Frequently Asked Questions
Should all checks use the same DNS resolver?
Use each network's normal resolver for a realistic comparison, then repeat with a shared public resolver when isolating a DNS problem.
Can I compare a browser load test with a ping test?
No. Ping checks network reachability, while HTTP checks the web service. Compare HTTP with HTTP and ping with ping.
How long should a comparison run?
Run checks at the same interval for at least 15 to 30 minutes. Short one-off tests can reflect a brief routing delay rather than a pattern.
