How DownCheck Works
Most outage tools count user complaints. DownCheck runs real network probes from 3 independent locations simultaneously and gives you a confidence score — not just a dot. Here is exactly how every check works, step by step.
Active probing, not crowd-sourcing
Most "is it down?" tools work by counting user complaints. When enough users report a problem, the tool marks the service as "down." This sounds reasonable — until you realize the problem: user reports lag by 15–30 minutes behind actual incidents, and they can spike for reasons unrelated to real outages (app updates, local ISP issues, confusion).
DownCheck takes a different approach. When you check a service, we immediately send real network requests to that service from multiple independent vantage points and report what we actually observe — not what users are saying on social media.
User-report tools (e.g. Downdetector)
- Count how many users click "I have a problem"
- Compare to a historical baseline
- Declare an "incident" when complaints spike
- 15–30 min lag from real outage to detection
- Cannot tell global down from local issue
- False positives from app updates, news events
DownCheck (active probing)
- Sends live HTTP requests to the actual server
- Queries 4 independent DNS resolvers in parallel
- Routes a probe through Cloudflare's edge network
- Results in < 15 seconds from check to verdict
- Distinguishes global outage from DNS failure
- Confidence score tells you how certain the result is
The 3-probe system
Every check runs three probes simultaneously. Each probe uses a completely different network path, infrastructure provider, and protocol — so a failure in one probe is meaningful, and agreement across all three is very reliable.
Direct HTTP Probe
A real HTTP GET request is sent directly to the target URL from our server (Railway infrastructure). We measure the HTTP status code, response time, SSL certificate validity, and whether the server responds at all.
Follows redirects: Yes
Validates SSL: Yes
Network: Railway / AWS
Cloudflare Edge Probe
A second request is routed through a Cloudflare Worker deployed on Cloudflare's global anycast network (AS13335). This probe comes from a different autonomous system entirely — so if our Railway server can't reach a site but Cloudflare can (or vice versa), we know it's a routing issue, not a global outage.
Reports: data center (colo), country
Response time: measured independently
DNS Health Check
We query 4 independent DNS resolvers in parallel. DNS failure means the domain itself can't be looked up — often the first sign of a serious outage or domain expiry. We check all 4 simultaneously and report which ones succeed.
Counts as: 4 sub-probes
Reports addresses found
The 4 DNS resolvers we query simultaneously:
How we calculate the verdict
After all probes complete, we combine them into a single up ratio: the number of probes that succeeded divided by the total number of active probes. Each probe is weighted equally. The DNS probe contributes 4 sub-results (one per resolver).
| Probe | Counts as | Success condition |
|---|---|---|
| HTTP (direct) | 1 probe | Server responds (any HTTP status code), or connection successful |
| Cloudflare Edge | 1 probe | Cloudflare Worker receives a valid response from the target |
| DNS (Google) | 1 sub-probe | Domain resolves to at least 1 IP address |
| DNS (Cloudflare) | 1 sub-probe | Domain resolves to at least 1 IP address |
| DNS (Quad9) | 1 sub-probe | Domain resolves to at least 1 IP address |
| DNS (OpenDNS) | 1 sub-probe | Domain resolves to at least 1 IP address |
The ratio (successes ÷ total active probes) is then mapped to a verdict and confidence score:
| Up ratio | Verdict | Confidence | Meaning |
|---|---|---|---|
| 1.00 (all pass) | Up | 97% | Every probe succeeded — globally reachable |
| ≥ 0.67 | Likely Up | 72% | Most probes passed — minor routing issue or temporary blip |
| > 0.00 | Likely Down | 72% | Most probes failed — partial or regional outage likely |
| 0.00 (all fail) | Down | 97% | Every probe failed — globally unreachable |
We deliberately do not use 100% confidence. No tool checking from a fixed set of locations can be 100% certain — geographic routing differences, CDN behaviours, and Anycast mean a service can be unreachable from some locations but working in others. Our confidence scores reflect this reality honestly.
What each status means
Service is globally reachable
All probes succeeded. The service is responding from our HTTP server, Cloudflare's edge, and all 4 DNS resolvers. If you personally can't reach it, the problem is on your end — your ISP, router, DNS cache, or browser.
Mostly reachable — minor issue detected
Most probes passed but at least one failed. This can mean a temporary spike, a single DNS resolver having issues, or a routing anomaly in one region. Try again in a few minutes — this status usually resolves on its own.
Mostly unreachable — probable outage
Most probes failed. The service is likely experiencing an outage or severe degradation. One probe may have succeeded due to cached DNS records or partial CDN coverage. Check the service's official status page for confirmation.
Service is globally unreachable
Every single probe failed — HTTP returned no response, Cloudflare edge couldn't reach the server, and all 4 DNS resolvers failed to resolve the domain. This is a high-confidence global outage or a domain-level failure.
Background monitoring — 56 services, every 5 minutes
For the most popular services, DownCheck doesn't wait for you to trigger a check. Our server automatically probes 56 top services every 5 minutes, around the clock. This means when you open a status page for Google, Discord, or IRCTC, the check history is already populated — you're seeing real, recent data, not a blank slate.
The background checker runs in batches of 5 services at a time with a 1.5-second delay between batches to avoid flooding any single service with requests. Each auto-check result is stored server-side and displayed on the service's status page as the "Recent Check History."
- 56 services monitored automatically
- Check interval: every 5 minutes
- Batch size: 5 services (with 1.5s pause between batches)
- History retained: last 10 results per service (in-memory, resets on restart)
- Homepage service cards show live status dots from this data
Limitations — what DownCheck cannot detect
Honesty matters more than appearing infallible. Here is what our probing system cannot reliably detect:
Local or ISP-specific outages. If your internet service provider is blocking or throttling a specific service, our probes (which run from Railway and Cloudflare infrastructure) will still reach the service and report "Up." This is correct from a global perspective — the service is up — but you won't be able to access it. Use a VPN or mobile data to test whether this is the case.
Login / account-specific failures. If a service's homepage loads but authentication is broken, our probes won't catch this. We check reachability, not functionality. A service can be "Up" in our results and still have a broken payment system or login page.
Geographic-only outages. Some services are up globally but down in a specific country (e.g., due to government-mandated blocking or regional CDN failure). Our probes run from Railway (US region) and Cloudflare (nearest PoP). They may not reflect what users in a specific region experience.
Slow / degraded (not down). A service can respond to our HTTP probe in 9 seconds (just under our 10-second timeout) and we'll report it as "Up." Severe degradation without full unavailability is difficult to distinguish from normal operation using a single probe. Response times are shown in the probe details to help.
Check a service right now
See our 3-probe system in action. Enter any URL or pick a service.
Check a service →