This is the repair guide, not the checker. Confirm the outage first with the free website down checker (no signup, instant, from outside your network), then diagnose the lowest failing layer: DNS, TCP, TLS, HTTP, application, or content. That order prevents wasted restarts based on one person's cached result.
Paste the URL in the website down checker. If the checker says the site is up, the problem is local (DNS cache, VPN, ISP). If it says down, isolate the layer, roll back if you can, and prevent the next incident.
For a 60-second yes/no without remediation, use the outside-in check. For any site you operate, set up a free uptime monitor so you are not the last to know.
Website Down: The Fast Triage Sequence
Once the website down checker (or another outside check) confirms a real outage:
- Try a different DNS resolver — switch to
1.1.1.1(Cloudflare) or8.8.8.8(Google) to bypass a cached or poisoned local DNS record. - Flush your local DNS cache —
ipconfig /flushdnson Windows,sudo dscacheutil -flushcacheon macOS. - Check provider status and your own telemetry — a provider incident may explain the symptom, but verify that its affected service and region match yours before waiting instead of mitigating.
Then work the failing layer: DNS, SSL, host/server, or a recent change.
Step 1: You Already Confirmed It From Outside
Your own browser and Wi‑Fi can lie. The website down checker is the outside-in test: if it reports down, treat it as a real outage and continue below. If it reports up but you still cannot load the site:
- Turn off Wi‑Fi and use mobile data (or the opposite).
- Try another device, or an incognito window.
- Flush DNS and try
1.1.1.1/8.8.8.8.
If it works on mobile data but not Wi‑Fi, the issue is your local network or ISP — not hosting. For sites you run, a free uptime monitor repeats this check every few minutes so you are not doing it by hand.
Step 2: Rule Out DNS Issues
Often the site is up, but DNS is wrong or slow. Your browser can't find the server, so the page "doesn't load."
Check DNS resolution
Use dig or nslookup (or an online DNS lookup tool) and query your domain:
dig yourdomain.com
- No results or wrong IP — DNS is misconfigured or not propagated. Check your DNS provider (e.g. Cloudflare, Route53, your registrar) and fix the A/AAAA records.
- Slow response — DNS might be slow or overloaded; consider a faster DNS provider or CDN.
Flush local DNS cache
Your computer or router might be caching old DNS:
- Windows:
ipconfig /flushdns - macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Router: Reboot or clear DNS cache in admin panel.
Then try loading the site again.
Step 3: Check SSL and HTTPS
If the site loads over HTTP but not HTTPS (or shows a certificate warning), the problem is SSL/TLS, not the server itself.
Certificate expired or invalid
Browsers block or warn on expired or invalid certificates. Check:
- Your hosting or SSL provider (Let's Encrypt, Cloudflare, etc.).
- Whether auto‑renewal is enabled and actually ran.
- That the certificate matches the domain (e.g. no
wwwvs non‑www mismatch).
Fix by renewing the certificate or correcting the domain. Use the free SSL certificate checker for a one-off inspection, then add SSL monitoring so you get alerted before expiry.
Mixed content or redirect loops
- Mixed content — Page is HTTPS but loads scripts/images over HTTP; some browsers block them and the site can look "broken."
- Redirect loop — HTTP → HTTPS or
www→ non‑www (or vice versa) misconfigured, so the browser gives up.
Check the browser console and Network tab for blocked requests or repeated redirects, then fix your links and redirect rules.
Step 4: Check Your Hosting and Server
If DNS and SSL look fine but the site is still down, the issue is likely hosting or the application.
Host status page
Check your host’s status page (e.g. status.aws.amazon.com, status.cloudflare.com) for incidents in your region or service.
Server and application
- 500 errors — Bug or misconfiguration in your app; check logs (e.g. PHP, Node, Django) and recent deploys.
- 502/503 — Server overloaded or app not running; restart the app or scale up.
- Timeout — Server too slow or unresponsive; check CPU, memory, database, and slow queries.
Use uptime monitoring that checks your live URL (and key pages) every 1–5 minutes so you see exactly when it went down and when it came back.
Step 5: Correlate the Failure With Recent Changes
Quick checklist of usual suspects:
| Change | What can go wrong |
|---|---|
| DNS change | Wrong or old records; long propagation. |
| SSL renewal | Expired cert, wrong domain, renewal failed. |
| Code deploy | Bug, crash, or missing env vars. |
| Plugin/theme update (WordPress) | Conflict, white screen, 500 error. |
| Hosting migration | DNS not updated, wrong config, firewall. |
| CDN/firewall change | Blocked traffic, wrong origin, cache issues. |
If the site failed immediately after a reversible change, prefer the documented rollback path. Do not blindly restore DNS or certificates: preserve evidence, confirm the change is causal, and avoid turning a partial outage into a broader one. The incident runbook guide explains how to record decisions and ownership under pressure.
How to Avoid "Is My Site Down?" Panic Next Time
Reacting only when someone reports a problem means you're always one step behind. To get ahead:
- Use uptime monitoring — A service that hits your URL from multiple locations every few minutes and alerts you (email, SMS, Slack) when it's down or slow.
- Monitor SSL — Get alerts before your certificate expires so you never go down due to expiry.
- Use a status page — When something does go wrong, a status page (e.g. status.yourdomain.com) lets you say "we know, we're fixing it" instead of leaving users guessing.
With monitoring, you know the site is down before users have to ask "is my website down?"
Quick Checklist: Diagnose a Confirmed Outage
- Confirm with the website down checker (outside your network).
- If the checker says up, try another device and network (e.g. mobile data).
- Verify DNS (dig/nslookup) and flush local DNS cache.
- Confirm SSL is valid and not expired; check for redirect loops.
- Check host status page and your server/app logs.
- Review recent changes (DNS, SSL, deploy, plugins, hosting).
- Set up uptime + SSL monitoring so you're alerted next time.
Final Thoughts
Once the website down checker confirms a real outage, rule out DNS and SSL, then look at hosting and recent changes. Fix the failing layer — and with monitoring in place, you'll know about the next incident before your users do.
Frequently Asked Questions
How can I tell if a website is down for everyone or just me?
Use the website down checker. If the external check fails, the outage is real. If it succeeds and you still cannot load the site, the problem is local: DNS cache, a VPN, a firewall, or your ISP.
Is there a free website down checker?
Yes — the website down checker tests any URL from outside your network with no sign-up. For a site you operate, add a free uptime monitor so the same check runs on a schedule.
What does it mean when a site is "down for me but not for others"?
It almost always means a local issue, not a real outage. The most common causes are a stale DNS cache (flush it with ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS), a VPN or proxy routing your traffic through a blocked region, a corporate firewall, browser cache holding an old error page, or an IP-based block at the host. Try a different network and an incognito window before assuming the site is broken.
Why does my website say "this site can't be reached"?
That browser error generally means your computer can't establish a TCP connection to the host. Likely causes, in order: DNS is not resolving the domain, the server is offline or rejecting connections, a firewall is blocking port 80/443, an SSL handshake failure on HTTPS, or a CDN/origin outage. Pinging the domain and running dig or nslookup tells you whether DNS resolves; if it does, the issue is server- or network-side.
How long does it usually take to fix a website outage?
Most short outages — bad deploys, DNS misconfigurations, certificate renewals — are resolved in 5 to 30 minutes once you have access and a clear root cause. Hosting-level incidents (provider, region, CDN) can run from 30 minutes to several hours. The fastest way to shorten an outage is to know it happened the moment it starts, which is why automated uptime monitoring with alerts beats waiting for a user to email you.
How do I prevent my website from going down in the future?
You can't prevent every outage, but you can prevent the surprise. Set up uptime monitoring with multi-region checks every 1–5 minutes, monitor SSL certificate expiry separately, keep DNS records and registrar credentials documented, test deploys in staging, and run a public status page so you can communicate during incidents instead of fielding individual "is your site down?" messages.