When your website stops loading, every minute feels like an hour. Organic traffic slows, ads burn budget without conversions, customer support tickets spike, and trust erodes. Knowing how to check if a website is down—quickly and accurately—is a critical skill for digital marketers, SEOs, and site owners. This comprehensive guide covers simple checks, technical diagnostics, and best practices to minimize downtime’s impact on revenue and rankings.

What “website is down” really means

“Down” can describe multiple failure types across the stack. Understanding the category helps you troubleshoot faster and communicate clearly with teams and stakeholders.

Local or device-specific issues: Browser cache, extensions, parental controls, captive Wi‑Fi portals, or OS firewall rules can block access for you while the site works for others.
Network or ISP issues: Problems with your router, DNS resolver, or internet provider can prevent name resolution or block routes to the site.
DNS failures: Expired domain, broken DNS records, DNSSEC misconfiguration, or slow propagation after changes can stop the hostname from resolving.
TLS/SSL errors: Expired or misconfigured certificates, cipher mismatches, or HSTS policies can block HTTPS connections.
Application errors: 5xx server errors, code deploy regressions, database overload, or misconfigured redirects can bring the app down.
Edge/CDN issues: CDN cache poisoning, WAF blocks, rate limits, or provider outages can selectively affect regions.
Planned maintenance: The site may be intentionally offline—but if there’s no status page or Retry-After header (503), users won’t know.

Quick checks: Is the website down for everyone or just me?

Before deep technical diagnostics, run quick user-level checks to rule out local issues.

Reload and check another browser: Try a hard refresh and open in a second browser to bypass quirky extensions and cached errors.
Open in an incognito/private window: This disables most extensions, cookies, and local storage.
Try a different device and network: Use mobile data, a different Wi‑Fi connection, or a colleague’s computer to rule out local network or machine issues.
Use a website down checker: Services that test from multiple regions can reveal if it’s a global or regional problem. Search for a “website down checker” and run a test from at least three regions.
Check the brand’s social channels or status page: Many brands post outage updates. If your company has a status page, verify whether an incident has been declared.

Understand the signals: Browser errors and HTTP status codes

When a site doesn’t load, your browser or HTTP client often provides clues. Learn to interpret them.

DNS errors: ERR_NAME_NOT_RESOLVED, NXDOMAIN. Indicates the domain isn’t resolving—likely DNS misconfiguration or propagation issues.
Network timeouts: ERR_CONNECTION_TIMED_OUT. Packets aren’t reaching the server—could be routing, firewall, or server down.
TLS/SSL errors: ERR_SSL_PROTOCOL_ERROR, certificate expired, hostname mismatch, or untrusted issuer.
HTTP errors: 4xx (client issues like 404) vs 5xx (server issues like 500, 502, 503, 504). 5xx usually indicate a site-side outage.

Common HTTP status codes and what they mean

Status	Meaning	Likely Cause	What to Do
200	OK	Site is up and serving content	Validate content and functionality; issue might be local if you still can’t see it
301/302	Redirect	Intentional redirect or redirect loop	Check destination URL; fix loops or mixed HTTP/HTTPS chains
403	Forbidden	WAF/IP block, hotlink protection, geo-block	Whitelist IPs, adjust WAF, verify authentication
404	Not Found	Missing page or routing error	Restore content or fix routes; audit internal links
429	Too Many Requests	Rate limiting or bot protection	Throttle traffic, implement backoff, adjust limits
500	Internal Server Error	Application crash, unhandled exception	Roll back deploy, check logs and error tracking
502	Bad Gateway	Upstream service failure, reverse proxy issue	Check upstream health, load balancer, and timeouts
503	Service Unavailable	Overload or maintenance mode	Scale resources; during maintenance, add Retry-After
504	Gateway Timeout	Slow upstream, database contention	Optimize queries, increase timeouts, scale databases

Network-level checks: DNS, Ping, and Traceroute

At the foundation, a domain name must resolve to an IP, and packets must reach that IP. These tests reveal where things break.

DNS resolution tests

Check A/AAAA/CNAME records: Confirm the hostname returns an IP (IPv4/IPv6). If not, DNS is likely the issue.
Try multiple resolvers: Query public resolvers like 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), and 9.9.9.9 (Quad9) to detect resolver-specific problems.
Inspect TTL and propagation: After changes, high TTL can delay updates; use several geographically diverse checks.
Verify DNSSEC: Mis-signed zones or missing DS records can cause resolution failures.
Check domain status: Ensure the domain hasn’t expired or been put on hold due to registrar or registry issues.

Connectivity tests

Ping: A quick test of reachability and latency. Note some servers block ICMP; a failed ping doesn’t always mean down.
Traceroute: Maps the path and shows where packets are dropped—useful for ISP or backbone routing issues.
Port check: Test if port 80/443 is open. If closed, a firewall or load balancer may be blocking access.

Command examples you can run from macOS/Linux/Windows Subsystem for Linux (run in a terminal):

dig yourdomain.com +short to see resolved IPs
nslookup yourdomain.com 1.1.1.1 to query a specific resolver
ping -c 4 yourdomain.com to test reachability
traceroute yourdomain.com or tracert yourdomain.com on Windows to map the route

Application-level checks: HTTP headers and content

Even if the network is fine, the application can fail. Inspect HTTP responses to confirm health.

Fetch headers: Use curl -I https://yourdomain.com to see status, server, cache headers, and any redirects.
Fetch full content: curl -v https://yourdomain.com shows the request/response flow and can reveal TLS negotiation issues.
Check key routes: Test homepage, product pages, login endpoints, and APIs. A site may partially work while critical paths fail.
Verify robots.txt and sitemap: If /robots.txt returns 5xx, search engines may reduce crawling (Source: Google Search Central).
Look for redirect loops: Multiple 301/302 hops or HTTP↔HTTPS oscillation can appear as a failure to users.

TLS/SSL certificate and HTTPS problems

Modern browsers treat HTTPS errors as hard stops. If users see certificate warnings, the site is effectively down.

Check expiry and hostname: Ensure the certificate covers all hostnames (including www/non-www and subdomains) and is not expired.
Verify chain of trust: Missing intermediate certificates cause trust failures on some devices.
ALPN and protocol support: If the server only supports outdated protocols (like TLS 1.0), newer clients may refuse to connect.
HSTS policies: With HSTS enabled, clients won’t allow insecure fallback to HTTP. A broken HTTPS configuration will block all access.
Test with OpenSSL: openssl s_client -connect yourdomain.com:443 -servername yourdomain.com prints the certificate and handshake details.

Third-party and edge risks: CDN, DNS provider, and host outages

Modern stacks rely on providers for DNS, CDN, WAF, DDoS protection, and hosting. Outages in these providers often manifest as site downtime, even when your application is healthy.

Check provider status pages: DNS and CDN incidents can be region-specific. Correlate with user reports from those regions.
Bypass the CDN (if safe): Test the origin server directly via its IP or an origin hostname to isolate edge vs origin issues.
Review WAF rules: New security rules may block legitimate traffic or API calls.
Rate limiting and bot protection: Aggressive bot detection can block real users, especially after marketing campaigns spike traffic.

Use online website down checkers and synthetic monitoring

External checks verify availability from multiple regions and networks and provide neutral evidence for stakeholders.

“Is it down?” checkers: Quick tests from diverse locations help confirm if an issue is global.
RUM vs synthetics: Real User Monitoring (RUM) reflects actual user experiences; synthetic monitoring simulates scripted visits and API calls, ideal for 24/7 outage detection.
Alerting: Configure alerts (email, SMS, Slack) for uptime and performance thresholds to reduce mean time to detect (MTTD).

Monitoring coverage checklist

Uptime pings: Home, checkout, login, search, and high-value landing pages
API endpoints: Authentication, payments, inventory
DNS health: Record existence, TTL, and DNSSEC validity
TLS/SSL checks: Expiry alerts and chain validation
Content verification: Assert that a key phrase renders on the page
Region diversity: At least five distinct geographic regions to catch localized issues

Command-line methods: Fast diagnostics for power users

Even non-engineers can learn a few commands to drastically speed up incident triage.

DNS: dig yourdomain.com A +short, dig www.yourdomain.com CNAME +short, dig yourdomain.com DNSKEY +short for DNSSEC checks.
HTTP: curl -I https://yourdomain.com to get headers; curl -s -o /dev/null -w “%{http_code} %{time_total}n” https://yourdomain.com to see the status code and time.
Port scan (single port): nc -vz yourdomain.com 443 to confirm the port is open.
TLS: openssl s_client -connect yourdomain.com:443 -servername yourdomain.com to inspect certificates.
Route: mtr -rw yourdomain.com combines ping and traceroute to spot packet loss.

Browser DevTools: Client-side visibility

Open DevTools (F12) and check the Network and Console tabs for errors that mimic downtime.

Network tab: Look for red requests and columns for status, size, and time. Filter for doc and xhr/fetch.
Console: CORS errors, mixed content blocks, or JS exceptions can break the app without server downtime.
Disable cache: In DevTools, disable cache and reload to avoid stale assets.

SEO considerations when a site is down

Downtime affects crawlability, indexing, and rankings. Marketers should limit damage by sending the right signals to search engines.

Serve 503 with Retry-After for maintenance: Tells crawlers to come back later, preserving rankings for short outages (Source: Google Search Central).
Avoid 404/410 for temporary issues: These tell search engines the content is gone; use 503 for temporary unavailability.
Robots.txt availability: If robots.txt returns a 5xx, Google may temporarily reduce crawling. Keep it lightweight and reliably served.
CDN cache rules: Consider serving a static cached version during origin outages to preserve user experience and crawlability.
Communicate clearly: Use a status page, banner, and social posts to reassure customers and reduce support load.

Benchmarks, stats, and the business impact of downtime

Understanding costs and industry benchmarks helps you set SLAs, justify monitoring budgets, and prioritize resilience work.

Average cost of downtime: Gartner has estimated the average cost of IT downtime at $5,600 per minute, with wide variation by industry and company size (Source: Gartner).
Outage severity trends: The Uptime Institute reported that the proportion of outages costing more than $100,000 has risen significantly in recent years, remaining above 60% in recent surveys (Source: Uptime Institute).
User tolerance for delays: Akamai reported that 53% of mobile users abandon sites that take more than 3 seconds to load—while not strictly “down,” slow is often perceived as down (Source: Akamai).
Reliability signals: Google’s SRE guidance emphasizes monitoring the four golden signals: latency, traffic, errors, and saturation, to detect availability issues early (Source: Google SRE).

Availability targets and allowable downtime

Use the table below to translate uptime goals into practical downtime budgets. This is essential for planning SLAs and on-call coverage.

Availability	Max Downtime/Month	Max Downtime/Year	Use Case
99.0%	7h 18m	3d 15h 36m	Internal tools, low-stakes sites
99.5%	3h 39m	1d 19h 48m	SMB marketing sites
99.9% (three nines)	43m 49s	8h 45m 57s	Typical SaaS target
99.99% (four nines)	4m 23s	52m 35s	High-availability commerce
99.999% (five nines)	26s	5m 15s	Mission-critical systems

A practical, step-by-step workflow to check if a website is down

Use this repeatable flow during incidents to accelerate detection, diagnosis, and resolution.

Confirm the symptom: Reproduce the issue locally. Take screenshots or HAR files from the browser Network tab.
Rule out local factors: Incognito, second browser, alternate network (mobile hotspot), and different device.
Verify external reachability: Run a “website down checker” from at least three regions.
Check DNS: dig or nslookup to confirm A/AAAA/CNAME records. Verify TTL and DNSSEC status.
Probe the network: ping (optional) and traceroute/mtr to identify packet loss or routing issues.
Inspect HTTP: curl -I for status and headers. Note 5xx vs 4xx and any redirect loops.
Validate TLS: Browser padlock details or openssl s_client to check expiration and chain.
Check provider status: DNS, CDN, WAF, hosting, and critical third-party APIs (payments, auth).
Correlate logs and metrics: Application logs, error tracking, APM, and infrastructure metrics for spikes in errors, CPU, memory, or connection pools.
Communicate: If confirmed, post to your status page, notify support and leadership, and set expectations for updates.

Diagnosing the cause: Match symptoms to likely root causes

Only some regions fail: Likely CDN edge, regional ISP routing, or geo-based firewall policy.
Only logged-in users fail: Session service, auth provider, or cookie domain/samesite settings.
API calls 5xx while static pages load: Backend service outage, database saturation, or API gateway limits.
Homepage redirects infinitely: Misconfigured canonical redirects, mixed www/non‑www, or forced HTTPS loops.
Certificate errors after deploy: New domain/subdomain not included in the cert, missing SAN, or wrong chain deployed.
Spike in 429: Rate limits due to bot surges or an aggressive marketing campaign. Implement backoff, adjust WAF rules.

What to do if it’s down: Communication and containment

How you respond is as important as restoring service. Clear communication protects brand trust and reduces churn.

Display a friendly maintenance page: If possible, serve a static page via CDN with a human message and expected timeline. Use HTTP 503 with Retry-After.
Update your status page and social feeds: Provide timestamped updates and known impact.
Pause paid campaigns: Stop or redirect traffic from PPC, paid social, and email to avoid wasted spend.
Offer alternatives: Provide phone/chat ordering or offline support options if commerce is affected.
Postmortem later, not during: Note timelines for later analysis, but keep incident comms concise during the event.

Preventative measures: Reduce the risk and blast radius

The best outage is the one that never happens—or only affects a small slice of users for a short time.

Monitoring and alerting: Combine synthetics, RUM, APM, and infrastructure metrics for full coverage.
Health checks and auto-healing: Use load balancer health checks to pull unhealthy nodes and auto-restart services.
Blue‑green or canary deployments: Limit the impact of bad releases and make rollbacks trivial.
Rate limiting and circuit breakers: Protect backends from overload and fail gracefully.
Staging parity: Test with production-like data and traffic patterns before releases.
Chaos and game days: Practice failovers and incident drills to lower mean time to recover (MTTR).
DNS and CDN resilience: Consider secondary DNS, reasonable TTLs, and origin shields.
Certificate automation: Auto-renewal and deployment pipelines for TLS certs to avoid expiration incidents.

Troubleshooting cheatsheet: Tools vs what they reveal

Tool	Layer	What It Reveals	Typical Insight
Website down checker	External	Multi-region availability	Global vs local issue
dig/nslookup	DNS	Record presence and resolver behavior	Propagation, DNSSEC issues
ping	Network	Reachability and latency	Packet loss, ICMP blocks
traceroute/mtr	Network	Hops and loss points	ISP/backbone congestion
curl	HTTP	Status codes, headers, redirects	5xx vs 4xx, loops, cache
OpenSSL	TLS	Certificate and chain	Expiry, mismatch, protocol
Browser DevTools	Client	Network timing and console errors	CORS, JS, mixed content
APM/Logs	App	Error rates and traces	Hot endpoints, slow queries

Marketing-specific playbook: Protect revenue and SEO during outages

Set up “safe” landing pages on the CDN: Cache key landing pages so campaigns can continue even if the origin fails.
Automate campaign pausing: Use monitoring webhooks to pause PPC and email sends when availability drops below threshold.
Build a communications kit: Pre-approved copy for banners, emails, social posts, and support macros to deploy in minutes.
Implement 503 templates: Clear customer messaging, helpful links, and expected recovery time with a Retry-After header.
Coordinate with sales and CX: Align on talking points and alternatives so prospects aren’t lost.

Common scenarios and how to check them quickly

1) The site works on mobile data but not office Wi‑Fi

Likely cause: Local firewall, DNS resolver problem, or corporate network policy.
Checks: Switch DNS to 1.1.1.1 on your device; try nslookup and traceroute; speak with IT about recent rule changes.

2) Only one country reports the site is down

Likely cause: CDN edge overload, ISP routing in that region, or geo-block.
Checks: Multi-region uptime checks; CDN provider status; temporarily bypass CDN for that region.

3) Users see “Your connection is not private”

Likely cause: Expired TLS certificate or hostname mismatch.
Checks: Browser certificate viewer; openssl s_client; verify auto-renewal.

4) Admins can log in; shoppers can’t checkout

Likely cause: Payments API outage, CORS issues, or a specific microservice failure.
Checks: Monitor API endpoint health; review error logs; check third-party provider status.

5) After a DNS change, some users can’t reach the site

Likely cause: TTL propagation; ISP caching.
Checks: dig against multiple resolvers; communicate an expected propagation window; keep old infrastructure up during transition.

Incident communications framework: Who to notify and when

First 10 minutes: Confirm scope; create an incident ticket; notify on-call engineers; place a holding note on the status page.
Within 30 minutes: Update internal channels (support, sales, leadership) with impact and ETA if known; pause affected campaigns.
Hourly until resolved: Provide timestamped updates; acknowledge uncertainty transparently if root cause is still under investigation.
After resolution: Post an incident review summary; share learnings and prevention steps with stakeholders.

SLAs, SLOs, and realistic targets for digital teams

Service Level Agreements (SLAs) are contractual promises to customers; Service Level Objectives (SLOs) are internal targets. Marketing, product, and engineering should align on what “acceptable downtime” means.

Define critical user journeys: Availability should be measured on flows that matter: view product, add to cart, checkout, and login.
Set error budgets: Allocate allowable downtime/latency so teams can ship features without overstepping reliability goals.
Measure user-centric availability: Combine status code success rates with page-level render success and API call success in the client.

Pre-launch checklist to avoid “day 1” downtime

DNS and TLS ready: Records deployed with sane TTLs; certificates issued and automated; alt names (www/non‑www) covered.
Health checks in place: Synthetic monitors for core routes; alerting tested.
Load testing: Simulate expected launch traffic; verify autoscaling and rate limits.
Rollback plan: Blue‑green or canary; database migration rollback strategy.
Third-party dependencies: Timeouts, retries, and fallbacks for payments, analytics, personalization, and auth.

How to document your “website down” runbook

A written runbook reduces panic and accelerates response. Keep it brief, actionable, and accessible.

Single-page quickstart: A one-page checklist with commands and contacts.
Escalation paths: On-call rotations and provider support phone numbers.
Decision trees: If DNS fails → who owns DNS; if TLS fails → who owns certs, and so on.
Templates: Status updates, banners, and customer emails.

Decision tree: From symptom to action

No resolution (NXDOMAIN): Check registrar status; verify nameservers; fix DNS apex/CNAMEs; validate DNSSEC.
Resolves but timeout: Run traceroute; check firewall, load balancer, and origin availability; check provider status.
Resolves and connects but 5xx: Roll back latest deploy; inspect logs and APM for hotspots; scale or fail over databases.
TLS errors: Renew/replace cert; add missing intermediates; verify SNI and ALPN.
Only some regions affected: Inspect CDN/WAF rules; check regional edges; consider temporarily disabling problematic rules.
Only logged-in users affected: Check auth/session services; cookie domain/path; CSRF and SameSite settings.

Frequently asked questions about checking if a website is down

How do I know if it’s just me or everyone?

Test in an incognito window, try another device and network, and run a multi-region “website down checker.” If multiple regions and networks fail, it’s not just you.

Does a failed ping mean the site is down?

Not necessarily. Many hosts block ICMP. Use HTTP checks (curl) and multi-region testers for a more accurate answer.

How long does DNS propagation take?

Typically minutes to a few hours, depending on TTL and resolver caching. Plan for up to 24–48 hours in worst cases and keep old infrastructure available during transitions.

What status should I serve during maintenance?

Serve HTTP 503 with a Retry-After header and a clear maintenance page. This preserves SEO signals for short outages.

Can slow performance look like downtime?

Yes. Users abandon slow pages, and timeouts can appear as failures. Monitor latency and error rates together to catch “soft” outages.

Will brief downtime hurt my SEO?

Short, infrequent outages with proper 503 responses usually have minimal impact. Persistent 5xx errors can degrade crawl budget and rankings.

Realistic incident examples and responses

Example: TLS certificate expired overnight

Symptom: “Your connection is not private” for all users.
Check: openssl s_client shows expiration yesterday.
Action: Issue emergency cert, deploy chain, enable auto-renew and alerts.

Example: DNS misconfiguration after adding a new subdomain

Symptom: ERR_NAME_NOT_RESOLVED only for new subdomain; main site fine.
Check: dig sub.example.com returns NXDOMAIN on some resolvers.
Action: Publish the missing record, lower TTL temporarily, validate with multiple resolvers.

Example: CDN WAF rule blocks checkout

Symptom: 403 on POST /checkout for many users; GET pages work.
Check: Logs show WAF “SQL injection” false positives.
Action: Adjust rule sensitivity, add allowlist for endpoint, retest and monitor.

Post-incident review: Learn and prevent

Timeline and impact: When it started, detection time, resolution time, users affected, revenue impact.
Root cause: Specific, technical cause, not just symptom.
Contributing factors: Gaps in tests, monitoring, docs, people/process issues.
Action items: Concrete, owners assigned, due dates set.
Follow-up: Verify actions in 30–60 days; run a drill to test prevention.

Your “website is down” emergency kit

Credentials and contacts: Registrar, DNS, CDN, hosting, and third-party providers; on-call rotation list.
Monitoring access: Dashboards for uptime, APM, logs, and infrastructure metrics.
Command snippets: A paste-ready sheet for dig, curl, openssl, and mtr.
Comms templates: Status page posts, social copy, and customer support macros.
Rollback scripts: Automated redeploy/rollback, database restore playbooks.

Key takeaways for marketers and site owners

Speed matters: Triage in minutes by ruling out local issues and confirming with multi-region checks.
Layer your diagnostics: DNS → Network → TLS → HTTP → App → Third parties.
Communicate clearly: Status updates reduce support load and maintain trust.
Design for resilience: Monitoring, caching, canaries, and automated failovers shrink downtime.
Protect SEO: Use 503s for temporary issues and keep robots.txt and sitemaps reliably served.

Checking whether a website is down—and why—doesn’t require guesswork. With the steps, tools, and playbooks above, you can isolate issues fast, communicate effectively, and protect both revenue and reputation.

Conclusion: Knowing how to check if a website is down is essential for modern digital teams. Start with simple, user-level checks to determine scope; move methodically through DNS, network, TLS, and application layers; and leverage multi-region monitoring to validate findings. Back this with clear communications, smart caching, 503 maintenance responses, and robust incident runbooks. By combining technical know-how with proactive resilience, you’ll cut detection and recovery times, safeguard SEO and paid media ROI, and maintain the trust your brand has worked hard to earn.

Check out other posts

How to check if a website is down