Is it just you, or is the website actually down? Here's how to check any website's status instantly — plus how to monitor services and get alerts when they go offline.
You click a link. The page doesn't load. You click it again. Still nothing. You stare at the screen for three seconds that feel like three hours, then instinctively open a new tab and type: "is [website] down?"
Congratulations, you've just joined roughly 4.2 million people who perform that exact search every single day. And most of them waste 5-10 minutes bouncing between unreliable tools and forum posts before getting a clear answer.
That's what this guide fixes. By the end of it, you'll be able to determine whether any website is actually down — for everyone or just for you — in under 30 seconds. And if you stick around, I'll show you how downdetectors work behind the scenes, how to troubleshoot the weirdest connectivity issues, and how to set up monitoring so you never get caught off guard again.
Let's start with the fastest possible path to an answer. If you're in a hurry, do this:
Step 1: Open a new tab and go to a website you trust — google.com, cloudflare.com, anything big. If that loads, your internet works. If it doesn't, the problem is your connection, not the website.
Step 2: Use a website status checker. Go to a site that monitors service health across hundreds or thousands of services. On akousa.net's downdetector, you can check real-time status for over 1,600 services organized into 8 categories. Search for the service, look at the current status level, and you'll know in seconds whether other people are experiencing the same issue.
Step 3: If the checker shows the service is up but you still can't reach it, the problem is likely on your end — DNS, cache, VPN, or ISP. We'll cover all of those below.
That's it. Three steps, thirty seconds. For 90% of situations, that's all you need.
But if you want to understand why things break and how to fix the trickier cases, keep reading.
Before we dive into the details, here's a text-based decision tree you can bookmark and follow any time a website stops working:
START: Website not loading
│
├─ Can you load google.com?
│ │
│ ├─ NO → Your internet is down
│ │ ├─ Check your router (lights, power, cables)
│ │ ├─ Restart router (unplug 10 seconds, plug back in)
│ │ ├─ Try mobile data on your phone
│ │ ├─ Check ISP status page (use phone data)
│ │ └─ Call ISP if nothing helps
│ │
│ └─ YES → Your internet works. Continue.
│
├─ Can you load the site on your phone using cellular data?
│ │
│ ├─ YES → Problem is your local network
│ │ ├─ Flush DNS cache
│ │ ├─ Clear browser cache
│ │ ├─ Disable VPN/proxy
│ │ ├─ Try a different browser
│ │ └─ Switch DNS to 1.1.1.1 or 8.8.8.8
│ │
│ └─ NO → The site might actually be down. Continue.
│
├─ Check a downdetector / outage tracker
│ │
│ ├─ REPORTS SPIKING → Confirmed outage
│ │ ├─ Check status page for updates
│ │ ├─ Check social media for ETA
│ │ ├─ Don't spam refresh (you're adding load)
│ │ └─ Wait it out or find alternatives
│ │
│ └─ NO REPORTS → Could be regional. Continue.
│
├─ Try accessing through a VPN
│ │
│ ├─ WORKS → Regional or ISP-level block/issue
│ │ ├─ Your ISP may be blocking it
│ │ ├─ Regional CDN node may be down
│ │ └─ DNS propagation may not have reached you
│ │
│ └─ DOESN'T WORK → Site is down or has blocked traffic
│ ├─ Check official status page
│ ├─ Search Twitter/X for "[service name] down"
│ └─ Wait and retry in 15-30 minutes
│
END
Print that out, tape it to your monitor, or save it as a bookmark. It covers about 95% of scenarios.
The fastest and most reliable way to check if a website is down for everyone is to use a dedicated status monitoring service. These tools check websites from multiple servers around the world, so they can tell you whether the site is truly unreachable or if it's just your connection.
Not all website status tools are created equal. The ones worth using share a few key traits:
Broad coverage. A tool that only tracks 50 services isn't going to help when your niche cloud accounting software goes down. The more services tracked, the more useful the tool. Services like akousa.net's downdetector monitor over 1,600 services — from the obvious ones like Google, Netflix, and Discord to regional banking apps and niche gaming platforms.
Categorized services. When you're trying to figure out if a problem is widespread, categories matter. If every streaming service is having issues simultaneously, that's a CDN problem, not a Netflix problem. Having services grouped into categories like social media, gaming, streaming, banking, cloud, email, telecom, and e-commerce lets you spot infrastructure-level failures at a glance.
Multiple status levels. "Up" and "down" aren't sufficient. Real-world service health exists on a spectrum. A good checker distinguishes between fully operational, minor issues, degraded performance, partial outage, major outage, and scheduled maintenance. Knowing that Spotify has "degraded performance" (songs are loading slowly) is very different from knowing it has a "major outage" (nothing works at all).
Historical data. Knowing a service is down right now is helpful. Knowing it goes down every first Monday of the month between 2-4 AM UTC is powerful. Historical outage archives let you spot patterns, plan around known maintenance windows, and evaluate whether a service's reliability is improving or degrading over time.
Side-by-side comparison. During complex outages, the ability to compare two services on the same screen is incredibly valuable. If both Slack and Notion went down at the exact same time, they probably share infrastructure. If Slack is down but Teams is fine, it's a Slack-specific issue. Comparison tools save you from playing detective.
Behind the scenes, most website status checkers combine two approaches:
Crowdsourced reporting. When thousands of users suddenly report problems with the same service at the same time, that's a reliable signal. The spike in reports creates a clear statistical pattern. Downdetectors aggregate these reports and display them as trend lines. A flat line means everything is normal. A sudden spike means trouble.
Automated health checks. The better trackers also send automated pings to services from multiple geographic locations on a regular schedule. If a service fails to respond from three different continents simultaneously, it's flagged as having issues — even before users start reporting problems.
The combination is what makes modern downdetectors reliable. Crowdsourced data alone can produce false positives (a viral tweet asking "is anyone else having trouble with X?" can trigger a flood of unnecessary reports). Automated monitoring alone can miss issues that only affect certain users, certain regions, or certain features. Together, they paint an accurate, real-time picture.
If you want to verify a website's status yourself without relying on a third-party tracker, you can check from multiple network paths:
This is the simplest multi-location test. Turn off Wi-Fi on your phone, open the website using mobile data, and see if it loads. Your phone's cellular connection uses a completely different network path than your home Wi-Fi — different ISP, different DNS resolver, different routing. If the site works on cellular but not on Wi-Fi, the problem is your home network.
Connect to a VPN server in a different country and try the website. VPNs route your traffic through a completely different network path, often with different DNS servers. If the website works through a VPN, you're dealing with a regional issue — your ISP might be blocking it, your local CDN node might be down, or DNS hasn't propagated to your area yet.
Sometimes the simplest approach works best. Send a quick message to a friend or colleague in another city (or country) and ask them to try the site. If it works for them but not for you, you've confirmed a regional or network-specific issue.
There are web-based tools that will ping a URL from multiple server locations and show you the results. These are useful for confirming whether a website responds from, say, New York but not from London. If the site is reachable from some locations but not others, you're likely dealing with a CDN problem or regional infrastructure failure.
DNS issues are one of the most common reasons a specific website won't load while the rest of the internet works fine. Here's how to diagnose and fix them.
Every website has a numeric IP address (like 104.21.32.1), but nobody wants to memorize numbers. DNS (Domain Name System) is the internet's phone book — it translates domain names you type (like youtube.com) into the IP addresses that computers actually use. When DNS breaks, your computer literally can't find the website even though the website is running perfectly fine.
Open your terminal or command prompt and run:
Windows:
nslookup example.com
Mac/Linux:
dig example.com
If you get an IP address back, DNS is working for that domain. If you get a timeout or "server can't find" error, DNS resolution is failing.
Flush your DNS cache. Your computer caches DNS lookups to speed things up. Sometimes this cache holds stale or incorrect data.
ipconfig /flushdnssudo dscacheutil -flushcache && sudo killall -HUP mDNSRespondersudo systemd-resolve --flush-cachesSwitch to a public DNS server. Your ISP's DNS servers can be slow, unreliable, or even censored. Switching to a public DNS often fixes connectivity issues instantly:
To change your DNS on most systems, go to your network settings, find the DNS configuration, and replace the automatic/ISP DNS with one of the addresses above.
Wait for DNS propagation. If a website recently changed its hosting or DNS records, it can take up to 48 hours for those changes to reach every DNS server in the world. During this window, some people can access the site while others can't. If a site was working yesterday but not today, and a friend in another country can still access it, DNS propagation is the likely cause.
Sometimes the problem isn't the website or your network — it's your browser holding onto outdated data.
Browsers cache website files (images, scripts, stylesheets) to load pages faster. But when a website updates its infrastructure, your cached version can conflict with the new setup, causing errors.
Opening the website in an incognito or private browsing window bypasses your cache and cookies entirely. If the site works in incognito but not in your regular browser, the problem is definitely cache or extension-related.
Extensions — especially ad blockers, privacy tools, and VPN extensions — can interfere with website loading. Try disabling all extensions temporarily and reloading the site. If it works, re-enable them one at a time to find the culprit.
If the site doesn't work in Chrome, try Firefox (or vice versa). Different browsers use different rendering engines and networking stacks. If the site works in one browser but not another, the problem is browser-specific.
This one catches a lot of people off guard. You're connected to a VPN for privacy or remote work, and suddenly certain websites stop loading.
VPNs route all your traffic through a remote server. This changes your apparent location, which can trigger:
Disconnect your VPN and try the site directly. If it works without VPN, you know the VPN was the issue. Try connecting to a different VPN server location, or add the problematic site to your VPN's split-tunneling exceptions (if supported).
Sometimes your ISP (Internet Service Provider) is the bottleneck, and no amount of cache-clearing or DNS-switching will help.
Run a speed test. Go to a speed test website and check your download/upload speeds. If they're significantly lower than what you're paying for, your ISP is having issues.
Check your ISP's status. Many ISPs have their own status pages or social media accounts where they report outages. You can also search a downdetector for your ISP specifically — if thousands of other customers are reporting problems, you'll see it immediately.
Use your phone as a hotspot. If your phone is on a different carrier than your home internet, create a mobile hotspot and connect your computer. If everything works perfectly through the hotspot, your home ISP is the problem.
Check outage maps. Some downdetectors include geographic outage maps that show where problems are concentrated. If there's a cluster of reports in your city, the ISP is almost certainly having a regional outage.
Call your ISP. Yes, really. I know the hold times are brutal, but if the outage isn't on their status page yet, your call helps them identify it. Plus, outages that affect your service quality may entitle you to credits on your bill.
Social media is often the fastest way to confirm a major outage — faster than official status pages, faster than automated monitoring, sometimes faster than the company's own engineering team realizes there's a problem.
When a major service goes down, humans do two things almost simultaneously: (1) try to refresh the page, and (2) go to social media to ask "is [service] down for anyone else?" This creates a near-instantaneous signal that's hard to miss.
Twitter/X: Search for "[service name] down" and sort by "Latest." If hundreds of people posted the same thing in the last five minutes, it's real. This is the single most reliable social media method.
Reddit: Check the service's subreddit (r/spotify, r/discord, etc.) or r/outages. Redditors are remarkably fast at identifying and documenting outages, and the upvote system quickly surfaces the most useful posts.
Mastodon/Bluesky: Increasingly, tech-savvy users post about outages here too. If you're checking a developer-focused service (GitHub, AWS, Vercel), the Fediverse tends to notice quickly.
Be cautious of one thing: social media can create false alarms. A single popular tweet asking "is anyone else having trouble with Gmail?" can trigger a wave of people who then check Gmail, notice it's slightly slow, and report it as down. Look for volume and consistency — hundreds of independent reports within minutes is real. A handful of tweets from the same timezone is probably a localized issue.
After tracking outages across hundreds of services, certain patterns become obvious. Knowing these helps you predict and understand downtime.
Many companies push code updates on Monday mornings. If a service starts acting up between 9 AM and noon UTC on a Monday, there's a good chance a software deployment introduced a bug. These outages typically resolve within 1-2 hours as the team rolls back the change.
Services that are fine at 3 AM often struggle at 8 PM when everyone's home from work and using the internet simultaneously. Streaming services, gaming platforms, and social media are especially susceptible. If a service is consistently slow between 7-10 PM in your timezone but fine at other times, it's a capacity issue, not an outage.
When a major infrastructure provider (AWS, Cloudflare, Google Cloud) has issues, dozens of seemingly unrelated services fail simultaneously. If your email, your project management tool, your CRM, and your accounting software all go down at the same time, it's almost certainly a shared infrastructure problem. Checking a comprehensive downdetector with category views makes this easy to spot — if every category is lighting up at once, it's infrastructure.
Planned maintenance usually happens during low-traffic hours (2-6 AM in the service's primary market). If a service goes down at 3 AM and comes back at 5 AM, check their status page — there's a good chance it was planned. The service should have communicated this in advance, but not all of them do.
Experienced engineers know: never deploy on Friday afternoon. But not every company follows this wisdom. Friday afternoon deploys that go wrong create outages that last through the weekend because fewer staff are available to fix them. If something breaks Friday evening and the company is slow to respond, this is likely why.
Some outages move across time zones as they follow peak traffic. A service might be down in Asia-Pacific first, recover, then go down in Europe, recover, then go down in the Americas. This pattern suggests the service has a capacity bottleneck that manifests wherever traffic is currently highest.
Every major service has a status page. And every major service's status page has, at some point, claimed "All Systems Operational" while the service was clearly on fire.
Detection takes time. Even with sophisticated monitoring, it takes time for automated systems to detect a problem, confirm it's real (not a false alarm), and update the status page. This can be 5-15 minutes for well-run teams.
Communication bureaucracy. In many companies, changing the status page requires approval from an incident commander, possibly a legal review of the wording, and sign-off from someone senior. By the time the page is updated, users have known about the problem for 30 minutes.
Reputation concerns. Some companies are slower to acknowledge outages because every minute of publicly declared downtime affects SLA commitments, customer trust, and potentially stock prices. This is short-sighted — users trust companies more when they're transparent — but it happens.
When a status page says "investigating increased error rates," that means: "It's broken and we don't know why yet."
"Monitoring a fix" means: "We think we fixed it but we're waiting to make sure it doesn't break again."
"A small number of users were affected" means: multiply whatever they're implying by at least 10x.
"This incident has been resolved" with a vague explanation means: they're still figuring out what happened and will publish a real postmortem later (or won't).
This is where independent downdetectors earn their value. They don't have any incentive to downplay problems. If 50,000 users report that a service isn't working, the tracker just shows the data. It doesn't care about the company's stock price or SLA obligations. When a status page says green but a downdetector shows a massive spike in reports, trust the data.
Something interesting has happened over the past few years: transparency about downtime has become a competitive advantage.
Companies like Cloudflare, GitHub, and Atlassian publish detailed postmortems after major incidents. These documents explain exactly what went wrong, why it happened, how it was fixed, and what they're doing to prevent it from happening again. They're incredibly valuable for the engineering community and they build trust with customers.
Some companies have even started publishing uptime statistics and incident histories proactively, turning their reliability track record into a marketing asset. If you can point to 99.99% uptime with full transparency about the 0.01%, that's more convincing than claiming 100% with no data.
Status pages have also become a PR tool. Some companies create beautiful, professionally designed status pages that are meticulously maintained — but only report a fraction of actual incidents. The page looks great, the uptime number is impressive, but anyone using the service knows reality doesn't match.
The worst trend is "silent degradation" — when a service is technically "up" (the homepage loads) but core functionality is broken (you can't send messages, uploads fail, search returns garbage). Many status pages don't differentiate between "the website loads" and "the website actually works," creating a false sense of reliability.
Don't rely solely on any single source. Cross-reference the official status page with an independent downdetector, social media, and your own experience. A comprehensive downdetector that tracks 1,600+ services with historical data and comparison tools gives you the unbiased view that official status pages sometimes can't.
If you run a website, app, or online service, you need to know about problems before your users tell you about them. Here's how to set up proper monitoring from scratch.
At minimum, you need something that checks if your website responds to HTTP requests every few minutes. If it doesn't respond, you get an alert via email, SMS, or Slack.
Most monitoring services offer a free tier that checks every 5 minutes from a single location. This catches total outages — the site is completely down. It won't catch regional issues, performance degradation, or partial failures, but it's infinitely better than nothing.
What to monitor:
Upgrade to checking from multiple geographic locations. This catches regional outages that single-location monitoring misses entirely. If your site is down from the London check but up from the New York check, you've got a CDN or routing issue that affects some users but not others.
You also want response time monitoring at this tier. A page that loads in 200ms normally but suddenly takes 8 seconds is functionally broken even if it's technically "up." Set alerts for response times that exceed 2-3x your normal baseline.
For mission-critical applications, set up synthetic monitoring that actually simulates user actions. Instead of just pinging a URL, these tools log in, navigate to a page, fill out a form, and verify the result. This catches application-level bugs that simple HTTP checks miss.
Real user monitoring collects performance data from actual users in their actual browsers. This is the gold standard because it shows you exactly what your users experience — including issues caused by specific browsers, devices, network conditions, or geographic locations.
Don't alert on every blip. A 2-second timeout followed by immediate recovery isn't worth waking someone up at 3 AM. Set your alerts to trigger only when a check fails from multiple locations for at least 2-3 consecutive minutes.
Escalation paths. First alert goes to Slack or email. If not acknowledged in 10 minutes, escalate to SMS. If not acknowledged in 20 minutes, escalate to phone call. This prevents alert fatigue while ensuring nothing gets missed.
Separate severity levels. A slow response time is a warning. Total unreachability from all locations is critical. Different severities should route to different channels and have different escalation timelines.
You've confirmed the outage. Now what? Here are practical steps beyond just waiting.
I'm guilty of this too. But every time you hit refresh during an outage, you're adding load to servers that are already struggling. The engineering team trying to fix the problem doesn't need thousands of users pinging the server every 2 seconds. Check once every few minutes, not every few seconds.
Every critical tool should have a backup:
If you're a business affected by the outage:
In order of speed and reliability:
Not all "website down" situations are actual website problems. Sometimes it's the internet itself.
Multiple unrelated sites are down: If Google, Netflix, Reddit, and your bank's website are all unreachable, it's not those services. It's your internet connection or a major backbone issue.
Everything is slow but nothing is completely dead: This usually indicates ISP congestion or a problem with a major internet backbone provider. Individual services might time out, but they'll occasionally load if you wait long enough.
Only sites in a specific country/region fail: This can indicate undersea cable damage, a country-level DNS issue, or government-imposed restrictions. These are rare but they happen.
A handful of companies form the backbone of the internet. When they have problems, the impact is massive:
When you see dozens of unrelated services failing simultaneously, one of these infrastructure layers is usually the culprit. A good downdetector with category views makes this immediately obvious — if social media, gaming, streaming, and banking all spike at the exact same moment, it's not a coincidence.
Something that confuses many people: an app can work while the website doesn't, or vice versa.
Separate backends. Many services run their mobile app and website on different server infrastructure. The app might communicate with api.service.com while the website uses www.service.com. They might even be in different data centers.
Cached content. Mobile apps often cache more aggressively than websites. Your app might show you content that was loaded an hour ago, making it seem like the service is fine — when actually it's been down for 30 minutes and you're looking at stale data.
Different CDN routing. Mobile carriers and home ISPs route traffic differently. Your phone's carrier might direct you to a healthy CDN edge node while your home ISP routes you to a broken one.
If an app seems to work but you suspect the service is down: try performing an action that requires a fresh server response. Send a message, create a new post, start a new search. If passive browsing works but active actions fail, the service is down and your app is showing cached content.
After years of troubleshooting connectivity issues, here's the toolkit I've settled on:
This is your first stop, every time. You want one that covers a broad range of services (1,600+ is ideal), organizes them into categories, provides historical data, and offers side-by-side comparison. I keep akousa.net's downdetector bookmarked because it covers all of those bases and displays clear status levels from "operational" to "major outage."
Write these down somewhere you can find them even when the internet is acting up:
Switching DNS is the single most effective self-service fix for "this one website doesn't load" situations.
Memorize these three:
# Test if a site responds
ping example.com
# Check DNS resolution
nslookup example.com
# Trace the network path
tracert example.com (Windows)
traceroute example.com (Mac/Linux)
These tell you whether the problem is DNS, routing, or the destination server itself.
A VPN is useful both for privacy and as a troubleshooting tool. When a site doesn't load, connecting through a VPN in a different country tells you immediately whether it's a regional issue.
Slow internet masquerades as websites being "down" when they're actually just timing out due to packet loss or extreme latency. A quick speed test clarifies this instantly.
Sometimes, after all the checking and troubleshooting, you discover that the website is up for everyone else and the problem really is on your end. Here's the complete checklist for fixing local issues:
C:\Windows\System32\drivers\etc\hosts/etc/hostsipconfig /release && ipconfig /renewIf none of these work and the site is confirmed up for everyone else, the issue might be at your ISP level. Contact them directly.
Minor outages for major services typically resolve within 15-60 minutes. Major outages can last 2-6 hours. The longest recent outages (like Meta's 2021 DNS disaster) lasted about 6 hours. If a service has been down for more than 6 hours, something is seriously wrong.
Absolutely. CDN issues, DNS propagation delays, regional server failures, and even government-level blocking can cause a website to be unreachable in one country while working perfectly in another. This is why checking from multiple locations (or using a VPN) is important.
Yes, if the downdetector or status tool allows user reports. Your report adds to the crowdsourced data that helps other users confirm there's a real problem. It also helps the service provider understand the scope and geography of the issue.
Status pages are updated by humans (or automated systems with thresholds). There's always a lag between when an outage begins and when it's reflected on the status page. For the first 5-30 minutes of any outage, the status page is essentially useless. Use independent downdetectors instead.
Yes, but from a user perspective, a website that takes 30 seconds to load is functionally the same as one that's down. Most browsers will time out after 30-60 seconds anyway. Extreme slowness usually indicates server overload, DDoS attacks, or infrastructure degradation.
Some downdetectors offer notification features. You can also set up a simple automated check using free monitoring tools — create a monitor for the service URL and set it to alert you when it becomes reachable again.
The internet breaks. Constantly. Services go down, DNS servers hiccup, ISPs have bad days, and sometimes your cat really does unplug the ethernet cable. It's not a question of if you'll encounter a downed website — it's a question of how quickly you can figure out what's happening.
The approach is always the same:
That's it. Four steps. Under a minute. And the vast majority of the time, you'll have a clear answer.
For those times when you need deeper insight — historical patterns, service comparisons, category-wide views — bookmark a comprehensive status monitoring tool. Having a single dashboard that tracks 1,600+ services across every major category means you're always one click away from the answer, whether it's a global AWS meltdown or just your router being dramatic.
The internet may be held together with duct tape and optimism, but at least now you know how to tell when a piece falls off.