Website outage check

Is your website down?

Run a quick reachability check, then use the command-line steps below to confirm whether the problem is your browser, DNS, SSL, network path, or the service itself.

Run a Website Check
Quick check

Test reachability from our side

Paste a domain or full URL. This makes a simple HTTP request and reports whether the endpoint responds.

Use this as a first signal, not the final diagnosis. Confirm with the manual checks below.
Triage path

How to check if a website is really down

Do the fast checks first. Deep debugging before basic confirmation wastes time and usually sends you in the wrong direction.

Change networks Try mobile tethering or another connection to rule out local ISP, router, or office network issues.
Check domain basics Use the WHOIS lookup and email DNS checker for related domain record issues.
Inspect SSL An expired or broken chain can make a working server look down in browsers. Run the SSL checker.
Confirm with commands Use ping, traceroute, and curl to separate network reachability from HTTP response problems.

Terminal commands

Ping: quick network reachability

Ping checks whether the host responds to ICMP packets. Some servers block ICMP, so a failed ping does not prove the website is down.

# Linux / macOS
ping -c 4 example.com

# Windows
ping -n 4 example.com

Traceroute: find where traffic stops

Traceroute shows the route packets take. It is useful when one network cannot reach the site but another network can.

# Linux / macOS
traceroute example.com

# Windows
tracert example.com

Curl: inspect the HTTP response

Curl tells you whether the server responds over HTTP and which status code it returns.

curl -I https://example.com

# Follow redirects
curl -L -I https://example.com

Online tools

What else to check

  • Recent DNS changes, low TTLs, or partial propagation.
  • Expired SSL certificates or broken intermediate certificates.
  • Rate limits, WAF rules, bot protection, or geo-blocking.
  • Server process health, logs, disk usage, and upstream dependency status.
  • Hosting provider status pages for wider regional or network incidents.
When to worry
  • Failed checks from multiple networks or regions.
  • SSL errors remain after cache and browser checks.
  • Provider status shows degraded network or compute service.
  • Curl returns repeated 5xx responses or timeouts.
Next step

Stop finding outages manually

StatusPage.me monitors websites and APIs from multiple regions, alerts your team, and keeps your public status page current.

Start Monitoring Free View Monitoring Network
Automation

Manual checks are useful once. Monitoring is what catches the next outage.

If a website or API matters, you need repeated checks, regional confirmation, alert routing, and a public place to explain what is happening. Manual commands are diagnosis. They are not coverage.

Multi-region checks

Confirm downtime from more than one location before waking someone up.

Instant alerts

Send failures to the right channel instead of waiting for users to complain.

Status page updates

Give customers one trusted place to check during incidents.

History

Track response time and uptime trends instead of relying on memory.

FAQ

Website down questions

Fast answers for the checks people usually run during an outage.

Try a different network, run a web-based uptime check, and confirm with curl or ping. If multiple independent checks fail, the issue is probably not just your browser or local connection.

No. Ping uses ICMP, and many servers block ICMP while still serving HTTP traffic normally. Use curl or an HTTP uptime checker before calling it an outage.

Curl shows whether the web server responds and which HTTP status code it returns. Timeouts, connection refusals, TLS failures, and repeated 5xx responses are stronger outage signals than a failed ping.

Use automated monitoring for any site, API, checkout flow, dashboard, or customer-facing service where downtime costs money, trust, or support time.