Is It Down? Check a Website Response

Enter the public domain you are authorized to check, without an account path, query string or private token. This tool checks the root of the host over HTTPS. If only a particular application page is failing, record that separately rather than assuming the root response describes the entire user workflow.

Choose a requested probe region, consent to the public measurement and start the check. The response identifies the actual probe. A website can behave differently by location, network, content-delivery edge or bot policy, so the origin of the request is part of the result.

Read the HTTP response code as an observation, not a single universal up-or-down label. A successful response differs from a redirect, a missing page, an access denial and a server error. A 403 response shows that something answered but refused the probe; it is not the same as no connection.

If the remote check responds but your browser still fails, compare the failing workflow with the tested root request. Your session, DNS cache, extensions or network route may differ. Avoid changing several settings at once. Keep one timestamped observation and the exact symptom so a later comparison remains meaningful.

The phrase is it down often combines several different questions: can a name resolve, can a connection open, does HTTPS negotiate, does a page respond, and does a logged-in application work? This component answers a narrow, observable part using an HTTPS HEAD request from a remote node. A HEAD response requests headers rather than the normal page body; some sites handle it differently from a visitor’s GET request. This limitation is shown explicitly. A failed probe can also reflect a provider problem or filtering, so failure alone does not justify declaring a global incident.

This is a one-time check, not an uptime history. It does not schedule later requests, send alerts or calculate availability over a period. The existing website-monitor widget page describes a different, recurring workflow.

An application can return HTTP 200 while showing an error page or failing after login. Conversely, a remote probe can receive 403 while real users are admitted. Test the actual authorized user path before making a broader statement.

Do not publish “down for everyone” from one sample. If you need incident confirmation, combine observations with the service’s official status communication and your own authorized monitoring records.

A probe receiving HTTP 403 has obtained an application-level response, even though access was denied. A probe timing out has not obtained that same evidence. Calling both results “website down” would erase an important distinction. If your own browser succeeds while the probe receives 403, a bot or network access policy is one possible explanation, not a confirmed cause. Check the service’s own access policy and authorized logs before deciding. Similarly, a root-path 200 response does not establish that checkout, search or account login succeeds.

Keep the question, input, observation time and source together. A bare address, percentage or status code is difficult to interpret later because it omits the connection and measurement context. When comparing two observations, note what changed between them: the target, network, VPN state, selected adapter, record type or remote origin. Change one relevant condition at a time when possible. That makes the comparison easier to explain without inventing a cause from one number.

Save only information you actually need. Network records can reveal infrastructure names and connection details, even when they do not contain a password. Remove unrelated identifiers before sharing a screenshot with another person. Never put private credentials in a domain field or publish an internal hostname as part of a public test. A copied result is a snapshot, not a promise that the same conditions still apply when someone reads it later.

Kepo is a Mac desktop-widget product for repeated checks and small workflows. A labeled troubleshooting note or a supported monitoring widget can keep the relevant context accessible while you work. The download link opens the product workflow; this article does not automatically install a configured diagnostic widget, transfer your network inputs or start a scheduled check. Confirm the actual widget’s capabilities before relying on it for ongoing observations.