Our Methodology

Is it down checker uses a dual-signal approach to detect website outages: automated server-side HTTP checks combined with crowd-sourced user reports. This hybrid methodology means we can detect both full-scale outages and partial or regional issues that server checks alone might miss.

How We Check Websites

Our monitoring infrastructure continuously checks websites using HTTPS requests from our servers. For each check, we measure:

• HTTP Status Code — Whether the server responds with a success (2xx/3xx) or error (4xx/5xx) code
• Response Time (Latency) — Time-to-first-byte in milliseconds, giving an accurate picture of server performance
• DNS Resolution — Whether the domain resolves correctly, catching DNS-level failures
• Connection Timeouts — Sites that fail to respond within the timeout window are flagged

Popular sites are checked every 60 seconds. All monitored sites are checked at least once per hour, with results stored for 24-hour historical analysis.

Crowd-Sourced Report Spike Detection

Server-side checks tell us if a site is reachable from our servers — but a site can be "up" for us while down for thousands of users due to CDN failures, regional routing issues, or application-level errors that don't affect the HTTP response code.

To catch these situations, we track user-submitted "It's down for me" reports and compare the current report volume against a rolling historical baseline. When reports spike significantly above normal levels, we elevate the site's status — even if our HTTP check says it's up.

The baseline is calculated as the average number of reports per hour over a trailing window. We then compute a spike ratio: the current reporting rate divided by the baseline rate. A minimum threshold of reports is required before any spike is triggered, preventing false alarms from low-traffic sites.

3-Tier Status System

We combine the HTTP check result with the crowd report spike ratio to produce one of three statuses:

Report Chart & Baseline Visualization

On each site's status page, the report chart shows the volume of user-submitted reports over the last 24 hours. The dashed red baseline line represents the historical average reporting rate. When the blue report bars exceed the baseline, it visually indicates elevated user complaints — the higher above the line, the more likely an outage is occurring.

Response time data is overlaid on the same chart (shown as a green line), allowing you to correlate user reports with actual server performance changes.

Outage Event Tracking

When a site's status transitions from "No Problems" to either "Possible Problems" or "Problems Detected," we record an outage event with a start timestamp. When the status returns to normal, we resolve the event and record its duration. This gives us accurate 24-hour, 7-day, and 30-day uptime statistics.

Uptime Percentage Calculation

Uptime percentages are calculated by subtracting total recorded outage minutes from the total minutes in the time window. For example, if a site had 15 minutes of outage in the last 24 hours (1,440 minutes), its 24-hour uptime would be:

(1440 − 15) ÷ 1440 × 100 = 98.96%

Limitations & Transparency

• Single check region — Our HTTP checks currently run from a single data center region. We may miss region-specific outages that don't affect our checking location.
• Crowd report accuracy — User reports are subjective. A user might report a site as "down" due to their own network issues. Our minimum report threshold and spike ratio math help filter noise, but false positives can still occur.
• Application-level issues — We check if a site responds to an HTTP request. A site could return a 200 status code while displaying an error page to users. Crowd reports help catch these cases.
• Privacy — IP addresses used for geo-location of reports are hashed with a daily rotating salt. Raw IPs are never stored persistently.