{"id":7274,"date":"2026-08-02T10:35:45","date_gmt":"2026-08-02T10:35:45","guid":{"rendered":"https:\/\/checksitestatus.com\/?p=7274"},"modified":"2026-08-02T10:36:19","modified_gmt":"2026-08-02T10:36:19","slug":"website-down-checker-is-it-down-right-now","status":"publish","type":"post","link":"https:\/\/checksitestatus.com\/fr\/website-down-checker-is-it-down-right-now\/","title":{"rendered":"Website Down Checker: Is It Down Right Now"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

You click a link. Nothing happens. The tab spins, then gives up with an error page you can’t quite parse. So you refresh. Then you refresh again, harder, as though the internet responds to frustration.

<\/p>

The question underneath all that clicking is simple: is this site broken, or is my end broken? Those two answers lead to completely different next steps, and guessing wrong wastes anywhere from ten minutes to an entire afternoon.<\/p>

A down checker settles it. You paste the URL into CheckSiteStatus, it makes a request from a server that has nothing to do with your laptop, your router, or your ISP, and it tells you what came back. If the site answers for us and not for you, the fault is somewhere between your device and the server. If it doesn’t answer for anyone, it’s genuinely down and there’s nothing you can do except wait or, if it’s your site, start fixing it.

<\/p>

Why your own browser is a bad witness<\/strong><\/h2>

There are more ways for a working site to look dead than most people realise.

<\/p>

Your browser cached a broken version of the page and keeps serving it back to you. Your DNS resolver is holding an old IP address after the site moved hosts, so you’re knocking on a door that isn’t there anymore. Your office firewall blocks the category the site falls into. Your VPN exits through a country where the site is geo-blocked, or through an IP range the site’s firewall has banned because someone else on that range misbehaved. Your ISP is having a routing problem that affects a slice of the internet but not all of it.

<\/p>

Any one of these produces the same symptom: a page that won’t load. None of them means the site is down. And you can’t tell them apart from inside your own browser, because everything you test still travels through the same broken path.

<\/p>

That’s the whole value of an external check. It’s a second opinion from somewhere that isn’t you.

<\/p>

What to do with each answer<\/strong><\/h2>

The checker says the site is up, but you still can’t reach it.<\/strong> The problem is local. Work through it in this order, because it’s roughly cheapest to most annoying:<\/p>

  1. Hard refresh the page (Ctrl+F5, or Cmd+Shift+R on a Mac).<\/li>
  2. Open the URL in a private window. This bypasses most cache and extension weirdness.<\/li>
  3. Switch networks. Turn off Wi-Fi and use mobile data. If the site loads, your network or ISP is the culprit.<\/li>
  4. Turn off your VPN if you’re using one.<\/li>
  5. Flush your DNS cache. On Windows: ipconfig \/flushdns<\/code>. On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder<\/code>.<\/li>
  6. Try a public DNS resolver like 1.1.1.1 or 8.8.8.8.<\/li><\/ol>

    Somewhere in that list is your answer, usually by step three.

    <\/p>

    The checker says the site is down and it isn’t yours.<\/strong> There’s nothing to fix. Wait it out. If it’s a service you depend on for work, check whether the company has a status page or a support account posting updates, because outages at large providers are usually acknowledged within twenty minutes.

    <\/p>

    The checker says the site is down and it is yours.<\/strong> Now the response code matters, and this is where a down checker earns its keep. “Down” is not one condition. It’s at least six, and they send you to different places.

    <\/p>

    Reading what came back<\/strong><\/h2>

    A blank error page in your browser hides the detail. The check doesn’t.

    <\/p>

    A 500<\/strong> means your application crashed while handling the request. Something you deployed, updated, or configured recently is the first suspect. Check the error log before you touch anything else.

    <\/p>

    A 502<\/strong> or 504<\/strong> means the web server is alive but whatever sits behind it is not cooperating. On a typical PHP or Node stack, that’s the process manager or the app itself. A 502 usually means it died; a 504 usually means it’s still thinking and ran out of time. Slow database queries are the classic cause of the second one.

    <\/p>

    A 503<\/strong> means the server is deliberately refusing, either because it’s overloaded or because someone left maintenance mode switched on. It’s also the correct code to serve during planned maintenance, since it tells search engines to come back later rather than treating the page as gone.

    <\/p>

    A 403<\/strong> means something is blocking the request. Firewall rule, WAF, file permissions, or an IP ban. Nothing in your application code will fix a 403.

    <\/p>

    Connection refused<\/strong> means nothing is listening at all. The web server process stopped, the host is down, or a firewall change closed the port.

    <\/p>

    A DNS failure<\/strong> means the domain itself won’t resolve. This is the one people miss for hours because it doesn’t look like a server problem at all. Expired domain registration, nameservers pointed at the wrong place, a missing A record after a migration, or propagation that hasn’t finished. The server can be perfectly healthy while being completely unreachable.

    <\/p>

    There’s one more result that trips people up: a 200 with a terrible response time<\/strong>. The site is technically up. It answers in nine seconds. Every real visitor left after three. Availability and usability are not the same measurement, which is why it’s worth checking performance and response times<\/a><\/strong><\/em> rather than treating a green light as the end of the story.

    <\/p>

    Down for everyone, or down in one country<\/strong><\/h2>

    Some outages are partial by nature, and they’re the hardest to diagnose because half your evidence contradicts the other half. Customers in one region complain while everyone in the office sees a working site.

    <\/p>

    This happens more often than you’d think. A CDN node fails in one region while the rest of the network is fine. A BGP routing problem makes your server unreachable from certain networks. A regional cloud zone has an incident. A country-level block or an overzealous firewall rule cuts off traffic from an entire ISP.

    <\/p>

    The only way to catch these is to test from more than one place, which is worth doing whenever the reports don’t match what you’re seeing. We’ve covered the specifics of checking availability from different countries<\/strong><\/em><\/a> if you’re dealing with an audience spread across regions.<\/p>

    The cost of finding out late<\/strong><\/h2>

    Downtime prices scale with whatever depends on the site. ITIC’s 2024 survey found that more than 90% of mid-size and large enterprises put an hour of downtime above $300,000, and the Uptime Institute’s 2026 analysis reported that one in five significant outages now tops $1 million.

    <\/p>

    Nobody reading this runs an enterprise data centre. But the small-site version of the math still stings. Annual revenue divided by 8,760 gives you a rough hourly figure, then add the ad spend burning on landing pages that don’t load, the support time, and the customers who just quietly go elsewhere.

    <\/p>

    The part worth focusing on isn’t the hourly rate. It’s the detection delay. An outage you catch in two minutes and an outage you catch in six hours are the same failure with wildly different bills, and the difference between them is entirely a matter of whether anything was watching.

    <\/p>

    Which is the honest limitation of manual checking: it only tells you about right now. It says nothing about Saturday at 4 am, which is exactly when hosting providers do maintenance and when nobody is looking. If the site matters, put a scheduled check on it and let the tool do the remembering. It’s worth understanding how automated status checks actually work<\/strong><\/em><\/a> before you configure one, mostly so you know what the results are and aren’t telling you.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\tHow do I check if a website is down for everyone or just me?<\/a>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t

    Run the URL through CheckSiteStatus. The check runs from an external server, so its result is independent of your browser, network, DNS cache, and ISP. If the tool reports the site as reachable and you still can’t load it, the problem is on your side. Trying the site on mobile data confirms this in about ten seconds.<\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t

    \n\t\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\tWhy does a website load on my phone but not my computer?<\/a>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t

    Your phone is on a different network with a different DNS resolver and no desktop browser cache, extensions, or VPN. The usual causes are a stale DNS entry, a cached broken page, a browser extension interfering with the request, or a firewall on your local network. Flushing DNS and testing in a private window resolves most of these.<\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t

    \n\t\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\tWhat does \"connection refused\" actually mean?<\/a>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t

    It means the server was reached but nothing accepted the connection on that port. The web server process has stopped, the machine is down, or a firewall is dropping the traffic. It’s different from a timeout, where the request goes out and nothing answers at all. Connection refused is a fast, definite rejection, which usually points at a stopped service rather than a network problem.<\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t

    \n\t\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\tCan a website be down for search engines but not for visitors?<\/a>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t

    Yes, and it’s a nasty one to catch. An aggressive firewall or bot rule can block crawler user agents while serving normal visitors fine. The site looks healthy to you and returns errors to Googlebot. If rankings drop with no obvious cause, checking what your server returns to non-browser requests is a good place to start.<\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t

    \n\t\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t<\/i><\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\tHow long does a website usually stay down?<\/a>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t

    It depends entirely on the cause. A crashed process restarts in seconds. A misconfigured deploy takes as long as it takes someone to notice and roll back. Expired domains can take a day or more once you factor in DNS propagation. Large provider incidents typically run one to six hours. The variable you control isn’t the repair time, it’s how long the problem sits undiscovered.<\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t