Check whether an outage is reproducible from outside your network
Test one exact URL from a Cloudflare location before treating a browser-only failure as a site-wide incident.
Website Down Checker
Free, no signup. Is it down from this independent Cloudflare vantage point? Check one URL for its current response, redirect path, and a bounded explanation.
Checks run from our server; we fetch the URL you enter and don't keep the results. This is one point-in-time request from a Cloudflare location, not a multi-region uptime monitor. HTTPS results show only whether a connection completed — never certificate expiry or full TLS details. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Sample report
Illustrative example — deterministic fixed response data
Reachable, but returning an error
The server responded with HTTP 503; that is different from a network outage.
842 ms · TLS handshake succeeded.
- 301 — http://example.test/status
- 503 — https://example.test/status
The example is classified from the shown status, hops, latency, and TLS state. It does not claim that example.test was requested.
How to use it
- Enter the exact page URL, including HTTPS and path when relevant.
- Choose Check website and read the reachability verdict before the timing.
- Inspect the redirect chain to confirm the final response is the page you expected.
- Follow the DNS, hosting, and RDAP links when the report receives no HTTP response.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Redirect chain
Next checks
Rate this tool
What the results mean
- Reachable means the final status is below 400 from this location.
- Reachable, but returning an error means an HTTP 4xx or 5xx response arrived; the network path worked.
- DNS name not found is used when the fallback DNS probe returns NXDOMAIN.
- TLS connection failed, timed out, or not reachable describe the bounded failure evidence; they do not identify a certificate or origin root cause.
How it works
A Cloudflare Worker makes a bounded external request, records the redirect hops, final status, elapsed time, and whether an HTTPS connection completed. When no HTTP status arrives, a fallback DNS result and the returned error text help distinguish NXDOMAIN, TLS failure, timeout, and other unreachable states.
Features
- One point-in-time external reachability check.
- Final status plus complete observed redirect path.
- Latency and limited TLS-handshake state.
- DNS fallback evidence and prefilled diagnostic handoffs.
Limitations
This is not continuous or multi-region monitoring. It cannot prove availability for every user, inspect application correctness behind a 200, expose certificate details, bypass bot protection, or distinguish every firewall, routing, DNS, origin, and transient network cause.
Frequently asked questions
Is the website down for everyone or just me?
This checker can only say what happened from one Cloudflare location at one moment. Compare another network or a multi-region monitor before concluding that everyone is affected.
Does an HTTP 500 mean the website is down?
The server is reachable, but it is returning an application or server errorA Page Indexing status in Google Search Console meaning Googlebot requested a URL and the server returned a 500-level HTTP error (500, 502, 503, 504) instead of a 200, so the page can't be indexed.. The tool labels that “reachable, but returning an error” rather than treating it as a network outage.
Can the checker diagnose an expired TLS certificate?
No. It reports whether a secure connection completed or failed, but the Worker interface does not expose certificate expiry, chain, hostname, or cipher details.
Why does the site work for me but show as unreachable here?
The target may vary by geography, IP reputation, firewall policy, DNS resolver, user-agent, cache, or timing. A single external vantage point is useful evidence, not an uptime consensus.
Feature requests for Website Down Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Separate an HTTP error from a network outage
Recognize that a 4xx or 5xx response means the server was reached even though the requested page is returning an error.
Verify the final response after redirects
Review every observed redirect hop and confirm that the final URL and status match the page you intended to test.
Capture bounded evidence during incident triage
Record status, response time, redirect path, TLS connection state, and fallback DNS evidence from one point in time.
Choose the next diagnostic check
Continue to DNS Checker, Hosting Checker, or Whois / RDAP Lookup when no HTTP response arrives and the failing layer needs more investigation.
Watch the full workflow
Website Down Checker walkthrough
Read the transcript
Website Down Checker
This beginner walkthrough explains how Website Down Checker tests one exact U-R-L from an external Cloudflare location. We will cover practical use cases, the interface, a complete fictional check, the difference between an H-T-T-P error and a network outage, redirects, timing, T-L-S, next checks, features, and the limits of a one-time observation.
Step 1
Website Down Checker answers a narrow question: what happened when one Cloudflare location requested this exact page right now? It records the final H-T-T-P status, every observed redirect, elapsed time, and whether an H-T-T-P-S connection completed. That is useful outside evidence. It is not a promise about every visitor, every region, or continuous uptime.
Step 2
Use the tool to see whether a failure is reproducible outside your own network, separate an H-T-T-P error from a network outage, verify the final response after redirects, capture bounded incident evidence, or choose the next diagnostic check. These use cases all begin with observation before anyone changes D-N-S, hosting, or application settings.
Step 3
Enter the exact page U-R-L, including H-T-T-P-S and the path when a specific page is failing, then choose Check website. The disclosure beneath the field matters: this is one point-in-time request from one Cloudflare location, not a multi-region monitor. T-L-S only says whether a secure connection completed; it never reports certificate expiry or full certificate details.
Step 4
The sample report previews the key interpretation. H-T-T-P five-oh-three is an error response, but the server still answered. That differs from a network outage where no H-T-T-P response arrives. The sample also shows elapsed time, a successful T-L-S handshake, and a two-hop redirect chain so you know what the live report will contain.
Step 5
The workflow is simple. Enter the exact U-R-L. Run the check and read the reachability verdict before the timing. Inspect the redirect chain to confirm the final response belongs to the page you expected. When no response arrives, continue with D-N-S, hosting, and registration evidence instead of guessing from the word down.
Step 6
For the complete example, enter status dot example dot test slash maintenance. Dot-test is reserved for documentation, so it is not a customer or public website. The capture fulfills the down-check endpoint locally with a fixed redirect and error response, and every external response is blocked.
Step 7
Choose Check website. The button changes while the bounded request is pending, then the report opens below the workflow. In a real check, the response can vary with time, geography, firewall policy, D-N-S resolution, caching, and bot protection. Here, the fixed local response makes every retake identical.
Step 8
The verdict says Reachable, but returning an error. The reason gives the evidence: the server responded with H-T-T-P five-oh-three. Reachable does not mean the page is healthy. It means an H-T-T-P response arrived, so this is different from a D-N-S failure, connection timeout, or another case where the checker receives no response at all.
Step 9
The same card reports eight hundred forty-two milliseconds and says the T-L-S handshake succeeded. Treat the time as one observed request, not a speed benchmark. T-L-S success only means the secure connection completed. It does not reveal the certificate expiration date, chain, hostname match, cipher, or the health of the application behind the connection.
Step 10
Redirect chain shows the requested maintenance U-R-L returning H-T-T-P three-oh-two, followed by the maintenance-window U-R-L returning five-oh-three. Read the last hop as the final result, but keep the complete path in your incident notes. A redirect can move the failure to a different page or host than the one you first entered.
Step 11
Next checks links to D-N-S Checker, Hosting Checker, and Whois or R-D-A-P Lookup. Those links are most useful when no H-T-T-P response arrives. D-N-S can test name resolution, Hosting Checker can describe the public delivery network, and R-D-A-P can show published registration evidence.
Step 12
The result guide defines four important states. Reachable means the final status is below four hundred. Reachable but returning an error means a four-hundred or five-hundred response arrived. D-N-S name not found requires an N-X-DOMAIN result from the fallback probe. T-L-S failure, timeout, and not reachable describe bounded evidence; none of them identifies a complete root cause by itself.
Step 13
Behind the interface, a Cloudflare Worker makes a bounded external request and records the redirect hops, final status, elapsed time, and limited H-T-T-P-S connection state. If no status arrives, a fallback D-N-S result and the returned error text help separate N-X-DOMAIN, T-L-S failure, timeout, and other unreachable states.
Step 14
The main features are one external reachability check, the final status with the complete observed redirect path, response time with limited T-L-S state, and fallback D-N-S evidence with prepared diagnostic handoffs. The report keeps each observation visible so you can save it with a timestamp and compare it with another network or later retest.
Step 15
This is not continuous or multi-region monitoring. It cannot prove availability for every user, inspect whether a two-hundred page is functionally correct, expose certificate details, bypass bot protection, or distinguish every firewall, routing, D-N-S, origin, and transient network cause. A site can work for you and fail here because the two requests do not share the same location, network, resolver, or timing.
Step 16
Save the exact U-R-L, check time, final status, redirect chain, response time, and T-L-S state. Retest from another network or multi-region monitor before declaring a broad outage. If the failure has no H-T-T-P response, inspect D-N-S and the public delivery path. If a four-hundred or five-hundred response arrived, correlate that status and timestamp with the application, proxy, or origin logs you control.
Confirm the response first. Diagnose the failing layer second.
Record the exact U-R-L, check time, final status, redirect path, response time, and T-L-S state. Then repeat the test from another network or monitoring location before calling the incident global. If no H-T-T-P response arrives, use the linked D-N-S, hosting, and registration checks to narrow the investigation without pretending that one probe identified the root cause.
Common issues & how to fix them
- Error Domain does not resolve Fix: Restore valid authoritative A, AAAA, or CNAME records for the hostname and confirm they resolve from multiple networks.
- Error Origin connection fails Fix: Restore origin connectivity by checking server health, firewall rules, listening ports, and upstream proxy configuration.
- Error Website returns a server error Fix: Inspect origin and application logs for the failing request, correct the 5xx cause, and verify a stable successful response.
- Warning Website returns a maintenance response Fix: End the maintenance window or serve a deliberate 503 with Retry-After, then restore the normal page when work completes.
- Error Website does not reach a healthy final URL Fix: Remove the redirect loop or broken hop and make the requested URL reach one healthy canonical destination directly.
- Warning Website response is unusually slow Fix: Profile the origin, cache repeatable work, and reduce backend or upstream latency until the endpoint responds within its target budget.