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.

Built by Patrick Stox

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.

Feedback
Report a bug

Found something broken in Website Down Checker? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
  
 
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.
  1. 301 — http://example.test/status
  2. 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
  1. Enter the exact page URL, including HTTPS and path when relevant.
  2. Choose Check website and read the reachability verdict before the timing.
  3. Inspect the redirect chain to confirm the final response is the page you expected.
  4. Follow the DNS, hosting, and RDAP links when the report receives no HTTP response.
 
 
 
     
     
     
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.
Next stepHosting Checker — look up the exact spec and expected values.

Explore more
ToolHTTP Header CheckerToolDNS CheckerToolWebsite Safety & Security CheckerArticle200 OKArticle204 No ContentArticleBlocked Due to Unauthorized Request (401)
 
 
 
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.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
       
 
Common issues & how to fix them
 
 
 
 
 
Website Down Checker · one finding
 
Domain does not resolve
 
Recommended action: Restore valid authoritative A, AAAA, or CNAME records for the hostname and confirm they resolve from multiple networks.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
 
 
 
Website Down Checker · one finding
 
Origin connection fails
 
Recommended action: Restore origin connectivity by checking server health, firewall rules, listening ports, and upstream proxy configuration.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
 
 
 
Website Down Checker · one finding
 
Website returns a server error
 
Recommended action: Inspect origin and application logs for the failing request, correct the 5xx cause, and verify a stable successful response.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
 
 
 
Website Down Checker · one finding
 
Website returns a maintenance response
 
Recommended action: End the maintenance window or serve a deliberate 503 with Retry-After, then restore the normal page when work completes.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
 
 
 
Website Down Checker · one finding
 
Website does not reach a healthy final URL
 
Recommended action: Remove the redirect loop or broken hop and make the requested URL reach one healthy canonical destination directly.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
  
 
 
     
  •  Warnings 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. 
    •