Website Down Checker

What Is A Website Down Checker?

A Website Down Checker requests a public website from outside your current browser and reports what that independent request observed. That distinction matters. Reloading a tab only confirms that your own device, browser, DNS settings, network, VPN, and internet provider could or could not reach the page. ClockTools adds an external Cloudflare edge observation, public DNS evidence, the final HTTP response, redirect details, and response timing.

People ask the same practical question in several ways: "Is my site down?", "Is my site online or not?", or "Does this page fail for everyone?" A useful answer cannot come from one green or red badge alone. ClockTools keeps the verdict beside the evidence so you can see whether the hostname resolved, whether a server answered, which status code arrived, whether the request moved through redirects, and where the final URL ended.

How Do You Check If A Website Is Down?

1. Enter a public domain or complete HTTP or HTTPS page address.
2. Run the check so ClockTools can resolve public DNS and request the URL from an external Cloudflare edge.
3. Read the overall verdict, HTTP status, response-to-headers time, redirect count, and tested edge.
4. Review the A and AAAA records, redirect destinations, final URL, content type, and disclosed server header.
5. Use the recommended next checks to separate a site problem from a browser, network, rendering, route, or port problem.

Test the exact address that appears broken. Checking only a domain homepage can miss a failing article, login, API path, redirect, or deployment route. Conversely, checking only a mistyped deep URL can produce a 404 even when the rest of the site is healthy. Compare the exact page with the homepage when the verdict says that a page is unavailable.

The result includes a timestamp and the Cloudflare edge code that handled the diagnostic request. Run another check after changing DNS, restoring a deployment, updating a firewall rule, or waiting for a temporary upstream problem. A fresh result is more useful than assuming an older result still describes the site.

What Does Each Website Status Verdict Mean?

Website is online means the final URL returned a successful 2xx response. That proves the anonymous external request received a successful HTTP answer. It does not prove that every image, script, API call, form, account, checkout, or browser interaction works correctly.

Website is responding describes a terminal 3xx response. Redirects commonly move HTTP to HTTPS, an old page to a new path, or one hostname to another. ClockTools follows up to eight public HTTP or HTTPS destinations and displays the chain. A missing destination, redirect loop, private destination, or excessive chain becomes an unreachable result instead of being followed indefinitely.

Reachable but restricted covers responses such as 401, 403, and 429. A server, gateway, firewall, rate limiter, or bot challenge answered, but it did not grant this anonymous probe ordinary access. That is different from an offline host. Owners should inspect security rules, while visitors should try the site normally without assuming the denial affects every user.

Page is unavailable covers other 4xx responses. A 404 says that this route was not found; it does not say that the domain or server disappeared. A 410 says that a resource is gone. Confirm spelling, capitalization, deployment paths, and redirects, then check the homepage before calling the whole website down.

Server error covers 5xx responses. The server or a gateway answered but could not complete the request. An application exception, failed origin, unavailable dependency, maintenance state, overload, proxy problem, or timeout can produce this category. The status narrows the investigation, but server, platform, and application logs are needed for the actual cause.

Unreachable means public DNS, connection setup, the response deadline, redirect safety, or another transport step prevented a usable final response. This is stronger outage evidence than a 403 or 404, but it still represents one edge at one moment. Regional routing and time-dependent incidents can produce a different result elsewhere.

Is My Site Down Or Is The Problem Local?

If ClockTools receives a successful response while your browser fails, start locally. Open a private window, disable an extension temporarily, clear the specific site's cache, check the address, and try another browser. Then compare Wi-Fi with mobile data, pause a VPN or proxy, review device time, and ask whether a firewall, parental filter, office network, or ISP policy could block the destination.

Local DNS can also disagree with the public resolver used by this Web Down Check. A router or device may hold an older address after a DNS change. Compare the public A and AAAA evidence, restart the local network only when appropriate, and allow for the record's time to live. Do not assume that clearing all browser data or changing DNS providers is necessary before simpler tests identify the scope.

If ClockTools also reports an NXDOMAIN result, transport failure, timeout, redirect loop, or 5xx response, look at the website side. Check the hosting dashboard, deployment state, DNS zone, CDN, certificate or HTTPS configuration, firewall, origin health, recent code changes, database, third-party dependencies, and provider incident notices. Test from another genuine network or region before declaring a global outage.

What Does ClockTools Check?

The diagnostic begins with public A and AAAA lookups through Cloudflare's documented DNS-over-HTTPS JSON interface. The report lists returned IPv4 and IPv6 addresses, CNAME records when supplied, the lowest visible TTL, the DNS status, and the lookup duration. A hostname that resolves only to localhost, private, internal, documentation, or reserved address space is blocked before an HTTP request is attempted.

ClockTools then sends a cookie-free, authorization-free GET request from the Worker and stops reading after response headers. It records the HTTP status, a familiar reason phrase when available, approximate elapsed time, final URL, redirect chain, content type, disclosed server header, cache-control value, retry-after value, and whether the final URL used HTTPS. Each redirect hostname receives the same public-DNS and private-destination checks.

The response time covers the external request and any followed redirects until final headers arrive. It is not a page-load benchmark, Core Web Vitals report, bandwidth test, or server processing profile. Network distance, edge routing, cold starts, congestion, security inspection, and redirect count can all influence one measurement. Use the separate Website Rendering Test when the page must be visually inspected across desktop and mobile viewports.

The status interpretation follows standard HTTP semantics rather than treating every non-200 code as downtime. The HTTP Semantics specification defines the classes, while the MDN status reference provides a practical index. That is why a restriction, missing page, server error, and transport failure receive different verdicts and troubleshooting steps.

What Can Make A Website Look Down?

DNS and domain problems include missing A or AAAA records, a broken CNAME, expired registration, nameserver mistakes, DNSSEC trouble, stale resolver data, and an incomplete migration. Compare the expected records with the evidence, but remember that DNS changes can appear at different times across recursive resolvers.

Hosting and application problems include a stopped origin, failed deployment, exhausted resources, broken configuration, application exception, database failure, unavailable queue, maintenance mode, and an unhealthy upstream. A 5xx code identifies the response family, not the exact component. Correlate the timestamp with hosting metrics and logs.

CDN, proxy, and firewall problems can block the probe, lose contact with the origin, cache an error, create a redirect loop, or apply a regional rule. A 403 may be deliberate bot protection rather than downtime. A 502, 503, or 504 can come from a gateway even when the application never received the request.

Browser and local-network problems include stale cache, service workers, extensions, incorrect system time, a VPN, a proxy, filtered DNS, captive portals, weak Wi-Fi, office policy, and ISP routing. A successful external result is a useful clue to compare another device or connection instead of repeatedly redeploying a healthy site.

One Check Is Not Uptime Monitoring

This Website Downtime Check records what one external Cloudflare edge observed at one moment. It does not calculate historical uptime, repeat checks on a schedule, confirm an incident from several regions, measure service-level objectives, or alert an owner. Continuous monitoring performs those jobs and should verify failures before paging people.

A successful 200 response is also narrower than a successful user journey. A page can return 200 while displaying an empty shell, stale content, a database message, broken JavaScript, missing images, a failed login, or a checkout error. Use rendering, synthetic interaction, application monitoring, and real-user evidence when the entire experience matters.

How Are Privacy And Safety Handled?

The checked URL must reach the ClockTools Worker because the external request cannot run only inside your browser. API responses are marked no-store, and the small recent-check list is kept in your browser's local storage so you can clear it. ClockTools does not forward your browser cookies, authorization headers, or login session to a target.

Test only public addresses. Do not submit private dashboards, reset links, signed downloads, access tokens, personal identifiers, or secrets in a query string. Localhost, private networks, internal hostnames, credential-bearing URLs, non-HTTP schemes, unsafe redirect destinations, redirect loops, and excessive chains are blocked. The tool checks availability evidence; it is not a vulnerability scanner, load test, or permission to probe systems you do not control.

Website Down Checker FAQ