How to check if your website is down (and get alerts when it is)
Is it down for everyone or just you? Five quick ways to check — from a phone on mobile data to a one-line terminal command — what each result means, and how to get an alert next time.
6 min readMonitoringUptimeGuides
Your site won't load. Before you panic, start editing code, or post "is it down?" in a chat, spend two minutes finding out what is actually wrong. "My site is down" can mean very different things:
- Nobody in the world can reach it.
- It's unreachable only from your network, your browser or your country.
- The server answers, but with an error page.
- The page loads, but it's blank or the important part doesn't work.
- The site is fine, and a service it depends on (a database, a payment provider) is down.
Each has a different fix. Here's how to tell them apart, from the fastest check to the most thorough.
1. Try from a different network
The quickest test needs no tools at all.
- Open the site on your phone with Wi-Fi turned off, so it uses mobile data.
- Or ask someone in another place to open it.
If it works on mobile data but not on your Wi-Fi, the site is probably fine. The problem is between you and it: your router, your internet provider, a VPN, a company firewall, or DNS cached on your computer. Restarting the router or turning off the VPN often fixes it.
If it fails everywhere, it's really down (or broken). Keep going.
2. Look at exactly what you get
"Doesn't load" is too vague to fix. Open the site in a desktop browser and note what you see:
- "This site can't be reached" / "Server not found" / DNS_PROBE_FINISHED_NXDOMAIN — the browser couldn't find the address. The domain may have expired, or its DNS records are wrong or were changed recently.
- "Your connection is not private" / NET::ERR_CERT_DATE_INVALID — the SSL certificate expired or doesn't match the address. Visitors see a scary warning and most leave.
- A page that says 500, 502, 503 or 504 — the server, or something in front of it, is answering with an error. 5xx errors are server-side problems.
- 404 Not Found on the home page — the host is up, but there's nothing at that address. Often a deployment that was removed or a misconfigured domain.
- The page loads but stays white or half-empty — the server is fine; the app crashed in the browser. See our guide to a blank white screen in a Lovable app; the same steps work for most AI-built apps.
- Everything loads, but sign-in or saving fails — usually the backend or database. If you use Supabase, check whether the project is paused.
For the last two, open the browser's developer tools (right-click → Inspect → Console) and reload. The red errors there tell you what failed.
3. Check from the command line
If you're comfortable with a terminal, two commands tell you a lot.
Does the server answer, and with what?
curl -I https://yourapp.com
The first line shows the status code, like HTTP/2 200 (fine) or HTTP/2 503 (server problem). If the command waits and then gives up, the server isn't answering at all. If it complains about the certificate, it's an SSL problem.
Does the domain point anywhere?
nslookup yourapp.com
If it says the domain can't be found, the problem is DNS or the domain registration, not your hosting. Compare the address it shows with what your host (Vercel, Netlify, Lovable…) tells you to use.
4. Check the services your site runs on
A lot of modern apps are put together from services: hosting on Vercel or Netlify, a database on Supabase, payments on Stripe, AI from OpenAI or Anthropic. If one of them has an outage, your site breaks even though you did nothing wrong.
Check them before you start debugging. Our live status pages show each service's official status and our own check, refreshed every 5 minutes:
- Hosting: Vercel, Netlify, Cloudflare, GitHub (for GitHub Pages)
- App builders: Lovable, Bolt, Replit
- Backend and APIs: Supabase, Stripe, OpenAI, Anthropic
Or see all of them on one page. If one is down, the honest fix is usually to wait, and to tell your users it's not you. We wrote a separate guide on telling whether a Vercel problem is you or Vercel.
5. Run a full checkup
If the site technically loads but something feels off, a checkup looks at the things you can't see at a glance. Pingbuddy's free checkup opens your site and reports:
- whether it answers, and how fast;
- when the SSL certificate and the domain registration expire;
- secret API keys left in the page's public code (a common problem in AI-built apps);
- whether the app's Supabase project is paused;
- and a few other basics, each with a plain-English fix.
It takes about 10 seconds and needs no sign-up.
Why you should never have to check by hand
Every method above has the same flaw: you only use it after you already suspect a problem. In practice, people learn that their site is down from a customer, a lost sale, or a friend — sometimes days later.
Uptime monitoring turns this around. A service checks your site on a schedule, from outside your network, and messages you the moment it fails. Good monitoring does a few things right:
- It checks often. Every few minutes, not once a day.
- It double-checks before alerting. One failed request can be a network hiccup. A good monitor checks again before waking you up.
- It tells you what's wrong. "Down" alone sends you back to step 1. A status code, a screenshot of what visitors see, and the likely cause save you the investigation.
- It reaches you where you'll see it. For most people that's a phone notification — Telegram or a chat app — rather than an email that sits unread.
- It notices when it's back. So you know the problem is over.
What normal uptime checks miss
Classic uptime monitors ask one question: did the server answer with a good status code? That catches a dead server, an expired domain or a broken deploy that returns 500.
It misses a whole class of problems that AI-built apps have all the time: the server answers "200 OK", but the page is blank because the JavaScript crashed, or shows "Invalid API key", or the database behind it is paused. To catch those, something has to open the page like a person would.
Setting up alerts in two minutes
Here's how it works with Pingbuddy (free for up to 20 sites):
- Paste your site's address on the Pingbuddy home page and sign in with your email or Google.
- Connect Telegram if you want alerts on your phone (email works out of the box).
- That's it. Your site is checked every 5 minutes. If it fails twice in a row, you get an alert with a screenshot of what visitors see and, for most outages, a plain-English explanation of the likely cause plus a prompt you can paste into your AI builder to fix it.
A real browser also opens your app every 30 minutes to catch blank screens and on-screen errors. And when a service your app is built on — Supabase, Vercel, Stripe and others — has an outage, you hear about that too, with a clear note that it's not your code.
Quick reference
| What you see | Likely cause | First thing to try |
|---|---|---|
| Works on mobile data, not on Wi-Fi | Your network, VPN or DNS cache | Restart router, turn off VPN |
| "Server not found" | Domain or DNS | Check domain expiry and DNS records |
| Certificate warning | Expired or wrong SSL certificate | Renew or reissue the certificate at your host |
| 500, 502, 503, 504 | Server or host error | Check host status and recent deploys |
| 404 on the home page | Deployment or domain setup | Check the domain is attached to the right project |
| Blank white page | JavaScript crash in the browser | Open the console, read the first red error |
| Loads, but sign-in or data fail | Backend or database | Check Supabase status and whether the project is paused |