How to Check if a Website Is Down (For Everyone or Just You)

Your website will not load, but the hosting provider says everything is operational. Start with the URL that failed: compare its response from another network, record the error and check the provider's reported incidents. Each answers a different question.

A provider-wide status page does not test your account or application. An external HTTP check tests a particular URL from a particular location. Neither establishes that every customer can complete a login or purchase.

The Fastest Way: Just Check

For a third-party service, search the Statusfield catalog and inspect its recorded status, source, timestamps and affected components. Depending on the service, the source may be provider reports or direct checks. A green record is useful context, not proof that your own workflow is healthy.

For your own website or API, use the following checks. If this is a recurring responsibility, uptime monitoring can request your public HTTPS URL on a schedule and evaluate the response using your rules.

Method 1: Use an External HTTP Check

Compare the same URL from a system outside your network. Check the response code and body, rather than relying only on an up/down label. If the external request succeeds while yours fails, investigate differences in network, location, account and request settings. If both fail, record both observations before deciding how broad the incident is.

Statusfield's service catalog and configured uptime monitors serve different purposes. Browsing a vendor record does not run a fresh test of any URL you paste into it. To monitor your own URL, create an uptime monitor and choose its response rules and check locations.

Method 2: Try a Different Network

Open the same URL on a phone using mobile data, then compare it with your usual connection. Keep the account and requested action as similar as possible. This can help separate a local connection issue from a service or regional issue; it does not establish the cause by itself.

Method 3: Ping the Domain

Ping can help investigate network reachability, but it does not test HTTP. A successful ping can coexist with a broken application, and some working hosts do not answer ping. Treat it as a supporting network observation rather than the deciding test.

Method 4: Check the HTTP Status Code

For a public URL you are permitted to check, this command makes a GET request, prints the response headers and caps the request time:

bash

curl --silent --show-error --max-time 15 --dump-header - --output /dev/null https://example.com/

Replace the example URL with the exact page or endpoint that failed. This command does not follow redirects automatically. Inspect the Location header and check the intended destination. The curl manual documents these options; a HEAD request made with curl -I can behave differently from a browser's GET request.

Response	What to investigate
`200`	The request succeeded at the HTTP level. Check the returned content and the action the user needs.
`301` or `302`	A redirect. Inspect the destination and whether it responds as expected.
`401` or `403`	Authentication or access restrictions, including differences between your browser and the check.
`404`	The requested resource was not found. Confirm the URL and routing.
`500`	A server error handling this request.
`502`, `503` or `504`	A gateway, availability or upstream timeout problem. Compare application and provider evidence.
No HTTP response	Inspect the connection error, DNS, TLS and timeout details.

See the HTTP status reference for individual code definitions. The code describes this response, not the health of every page or customer workflow.

Method 5: Check Their Status Page

Look for a reported incident covering the component and region you use. Review the latest update and its timestamp. Vendor reports can lag a problem or omit an account-specific failure. Statusfield can bring supported vendor reports together, but aggregating those reports does not make them independent tests of your application.

Method 6: Compare Other Reports

Recent reports from colleagues, customers or public discussions can help establish scope. Check whether they describe the same service, action, region and time. Social posts are supporting observations; they do not establish a cause or a recovery by themselves.

If Several Locations Are Affected

Record what failed, when it failed and who appears affected. Check application logs and vendor incidents together. Communicate the known impact while the cause is still being investigated. Use your existing runbook for retries, fallback behavior and customer updates; verify your own workflow before announcing recovery.

If Only Your Request Fails

Compare the exact URL, account, browser, network and request method. A private browser window can help isolate some browser state. Check VPN, proxy and DNS differences with the person responsible for your network before changing managed settings. A service can also have a regional or account-specific failure while other requests succeed.

Set Up Automatic Monitoring

For ongoing responsibility, choose the signal that matches the problem:

Vendor incidents: select the supported provider components you depend on and route their status changes to your team.
Your website or API: configure public HTTPS checks with the expected response codes, latency thresholds and optional text or JSON body rules. Each selected check location uses a monitor unit.
A job that stops checking in: use heartbeat monitoring, subject to current access availability. Send the check-in after your code verifies successful work.

Keep these signals in one Statusfield workspace. Use the quickstart to configure a monitor and verify its destination and routing rules. Compare plans for capacity, team access and supported channels. Setup time depends on your checks and integration permissions.

Frequently Asked Questions

Is the website down for everyone or just me?

Compare the same URL from another network and an external HTTP check. Failures from several locations suggest a broader issue, but do not prove that everyone is affected. A successful response elsewhere can point to a local or regional problem. Check vendor reports alongside those observations.

How do I check if a URL is down right now?

Request the exact URL and inspect its status, timing and content. A 200 response means that request succeeded at the HTTP level; it does not prove that login, payment or another complete workflow works. Statusfield uptime monitors check configured public HTTPS URLs on a schedule. The service catalog provides recorded vendor or direct-check status, depending on the service.

Why does a website load on my phone but not my laptop?

Compare the same URL, account and network where possible. Differences can come from DNS, VPN or proxy settings, browser state, account access, regional routing or the service itself. A phone using mobile data tests a different network as well as a different device.

Why does a website load sometimes but not other times?

Intermittent failures can come from the application, a dependency, a network path or only some servers or regions. Record the URL, response code and time of each failure, then compare successful and failed requests. A single successful check does not rule out an intermittent issue.

The website loaded but looks broken. Is it down?

The initial page can return successfully while scripts, images or API requests fail. Inspect the failing requests and test the actual action you need. HTTP monitoring can check configured response content, but a complete browser journey needs separate testing.

Is ping a reliable way to check if a website is down?

Ping tests network reachability, not the website response. A host can answer ping while its web application fails, and a working website can block ping. Use an HTTP request to inspect the URL and compare the result from another network.