How do you check if a site is down?

We send an HTTP request to the target domain from our servers and measure the response. If the server replies with a 2xx or 3xx status code, we mark it as UP. A 5xx response is classified as DOWN, and other codes (like unusual 4xx responses or timeouts) may indicate a DEGRADED state. We also record the round-trip latency of each check.

Why can I reach a site but your check says it's down?

Our checks run from specific server locations. A site may be reachable from your region or ISP but unreachable from ours — or vice versa. CDN-based sites, geo-restricted content, or regional outages can cause this discrepancy. Use the "Works for me / Down for me" buttons on any site page to share your real-world experience.

Why does it load for me but others report it's down?

This is common during partial outages or CDN edge failures. You might be served cached content, or your region's edge servers are still healthy while others are not. The community reports section on each site page shows what other users are experiencing in real time.

What should I do if a site is down?

First, try a hard refresh (Ctrl+Shift+R or Cmd+Shift+R). Clear your browser cache or try an incognito window. Check whether a VPN or a different DNS server helps. If none of that works and our check also shows it as down, the problem is likely on the site's end — check their official status page or social media for updates.

How often do you check a site?

We check on-demand — every time a user visits a site's status page. Results are cached for 90 seconds to avoid overwhelming the target server with requests. The uptime chart on each site page shows the full history of all checks we've run.

What does "Degraded" mean?

Degraded means the server responded, but with an unusual HTTP status code or took significantly longer than normal to reply. The site is technically reachable but may not be working correctly for all users — for example, serving error pages, returning unexpected redirects, or experiencing high latency.

Can I get notified when a site goes down?

Yes. The SiteAlive dashboard lets you monitor your own websites, receive alerts when status changes, review uptime history, and manage everything from one place instead of checking manually each time.

Overview

Get alerts when your sites go down.

Open dashboard →

On this page

How our checks work

Learn how website status checks work, how SiteAlive detects outages, what up, down, and degraded really mean, and which tools help explain DNS, routing, and server problems.

How your browser reaches a website

💻

Your BrowserSends a request

›

📖

DNS ResolverTranslates domain → IP

›

🔀

ISP / NetworkRoutes traffic

›

🖥️

Web ServerReturns the page

What happens when you check a website?

A website status check is more than a single page request. First, the domain has to resolve through DNS. Then the server has to accept a network connection. After that, the website still needs to return a usable HTTP response quickly enough to count as healthy.

That is why SiteAlive separates normal responses, degraded responses, and full outages. A site can be reachable but slow, reachable but returning bad server errors, or unreachable because the problem starts before the browser even reaches the web server.

If you want a deeper explanation of the layers behind those results, read our about monitoring page, browse live website status categories, or explore the full network tools section.

2xx / 3xx response

Degraded

Unusual code or high latency

Down

5xx or no response

How SiteAlive verifies an outage

Multiple independent checks must fail

A single failed request is not enough to declare a site down. SiteAlive requires consistent failures across repeated checks before changing a site's status — ruling out one-off request errors or transient server hiccups.

DNS, HTTPS, and TCP tests are combined

Each check runs three layers of verification: DNS resolution (can the domain be looked up?), TCP connection (can we reach the server's port?), and HTTPS response (does it return a valid HTTP status?). A failure at any layer is logged separately, so we can identify whether the issue is at the DNS level, the network level, or the application level.

User reports are compared to automated checks

Community reports from real users are cross-referenced with our automated results. When users report a site as down while our probes show it as UP, this signals a regional or ISP-level issue — not a global outage. When both agree, confidence in the status is much higher.

Temporary network glitches are filtered out

Brief connectivity issues — a momentary timeout, a single DNS failure, or a router blip — are common on the internet and do not reflect a real outage. SiteAlive filters these out by looking for sustained, repeated failures before marking a site as DOWN or DEGRADED.

Monitoring locations

SiteAlive runs checks from multiple independent network locations rather than a single server. This matters because internet connectivity is not uniform — a site can be fully reachable in one region while being completely unreachable in another due to routing failures, ISP-level blocks, or regional infrastructure problems. You can also compare regional signals on the global status map.

By probing from geographically distributed vantage points, we can distinguish between a true global outage (the site is down everywhere) and a regional issue (the site is only unreachable from specific locations or networks). This distinction is critical: a site that appears DOWN from one location might still be serving the majority of its users normally.

Location diversity also protects against false positives. If a single probe fails but all others succeed, the failure is attributed to a local network problem — not to the site itself. Only when failures are consistent across multiple independent locations is the site's status updated.

Checks run continuously and results update every few minutes, so the status you see reflects the site's current state — not a snapshot from hours ago.

Preventing false outage reports

Retry checks

When a request fails, SiteAlive immediately retries the check before recording any result. A site is only flagged as potentially down if multiple consecutive attempts all fail — a single dropped request never triggers a status change.

Geographic confirmation

Checks are run from independent network locations. If only one location fails but others succeed, we classify the issue as regional rather than a global outage. A site is marked DOWN only when failures are consistent across locations, not just from a single vantage point.

Cache delays

Results are cached for a short period between checks. This prevents a brief server hiccup — such as a restart or a momentary overload — from immediately appearing as downtime. If the site recovers within the cache window, no outage is recorded.

Why a single failed request is not considered downtime

The internet is inherently unreliable at a packet level. Timeouts, resets, and transient errors happen constantly due to routing changes, network congestion, or brief server restarts. Treating every failed request as downtime would produce constant false alarms. SiteAlive requires sustained, reproducible failures before updating a site's status.

Why status checks are not always perfect

No monitoring system — including ours — can give a 100% accurate picture of a site's status at all times. Here's why, and what that means in practice.

Temporary packet loss

The internet constantly experiences brief moments of packet loss due to congestion, router reloads, or link flaps. A check that fires during one of these moments may fail even though the target server is perfectly healthy. This is why a single failed check is never treated as a confirmed outage — we require sustained, repeated failures before changing a site's status.

ISP routing anomalies

Our monitoring servers reach a target site through a specific set of internet routes. If a BGP routing anomaly or ISP peering dispute temporarily disrupts those particular routes, our check may fail while users on different networks can still reach the site normally. The reverse is also true — our check can succeed via an alternate path while users on affected ISPs are completely blocked.

Caching delays

Results are cached for a short window between checks to avoid hammering target servers with repeated requests. This means the status you see may reflect a check from up to 90 seconds ago rather than the current moment. A site that just went down may still show as UP for a short period, and a site that just recovered may briefly appear as DOWN.

Regional outages

A site can be fully operational in one region while being unreachable in another — for example if a CDN edge node, a regional data center, or a specific transit link fails. Our probes run from fixed locations, so if the outage doesn't affect those locations, we may not detect it. Community reports from users in the affected region are the most reliable signal for these kinds of partial, geographic outages.

Use the SiteAlive dashboard for ongoing monitoring

The public status pages explain what is happening right now, but the website monitoring dashboard is where ongoing monitoring happens for your own websites.

Instead of running one-off checks manually, you can add your sites, track their latest status, review uptime history, and get alerts when something changes.

Start with the free dashboard for one site, then move to Pro or Scale if you need more sites, faster refresh intervals, and broader coverage.

How to investigate a failed website check

SiteAlive status pages tell you whether a site looks up, down, or degraded. If you want to understand why, these free tools help you move from a simple status result to a clearer technical explanation.

1. Confirm the domain resolves

A website can look down when the real problem is DNS. Start by checking whether the domain resolves to the expected records and whether recent DNS changes have spread worldwide.

DNS Lookup DNS Propagation

2. Test basic reachability

If DNS is healthy, the next question is whether the server or network path is reachable. Ping and traceroute help show whether packets get through and where delays or failures begin.

Ping Test Traceroute

3. Check what the web server returns

A server may be online but still broken for visitors. Looking at HTTP headers and speed results makes it easier to spot redirects, caching issues, timeouts, and slow application responses.

HTTP Headers Website Speed Test

4. Gather more technical context

When you need deeper insight, infrastructure and security tools help explain what sits behind the site, which IPs are involved, and whether misconfiguration may be contributing to the problem.

Website Intelligence Website IP Lookup Website Security Scanner

You can also browse the full network tools directory or read more about our monitoring approach.

Public status data

SiteAlive makes its monitoring results publicly accessible. Every site's current status, response time, HTTP status code, and check history are available through the site's status page — no account required.

For developers and integrators, machine-readable status data is available via a simple API endpoint. Each site page exposes a /api/status response with the latest check result in JSON format, making it easy to build dashboards, alerting pipelines, or status widgets on top of SiteAlive's data.

We believe monitoring transparency is important: when a site is down, you should be able to see exactly when it went down, what error was returned, and how long the outage has lasted — without having to log in or pay for a subscription.