My site is up for me but down for others

"Works for me" is the most dangerous state a site can be in: you have no error to debug and your users do. The cause is always some split between your path to the server and everyone else's - and finding the split is faster than staring at the symptom. (For the opposite problem, where the site is down for you, start with how to check if a website is down.)

How do I confirm it's really down for others?

Get one honest second opinion from a network that isn't yours. Your phone on mobile data with Wi-Fi off is the quickest. Better, ask a machine somewhere else entirely:

# From any VPS, CI runner, or a friend's terminal
curl -sSI https://example.com

If that fails while your browser works, you have a genuine split. Note how it fails before moving on - DNS error, timeout, connection refused, and TLS errors point at different culprits below.

Is your machine resolving a different address?

The most common split. You may be reading a DNS answer nobody else gets:

• A hosts-file entry. The classic: you added one during a migration and forgot it. Check /etc/hosts (or on Windows, C:\Windows\System32\drivers\etc\hosts) for your domain.
• A stale or fresh cache. After a DNS change, resolvers see the new record at different times. You may have the working answer cached while half the internet still holds the old one - or the reverse.
• Split-horizon DNS. On an office network or VPN, internal resolvers can answer with a private address that works only there.

Compare what you resolve against a public resolver:

dig example.com +short          # your resolver's answer
dig @1.1.1.1 example.com +short # what the public internet gets

Different answers end the investigation: fix the record, remove the hosts entry, or wait out the TTL. See DNS_PROBE_FINISHED_NXDOMAIN for the record-level fixes.

Are you on IPv4 while they're on IPv6?

Sites regularly ship with a correct A record and a broken AAAA record - an IPv6 address that points at a server not listening on it. Everything works for IPv4 visitors (you) and fails for IPv6-first networks, which includes most mobile carriers. Test both paths explicitly:

curl -4 -sSI https://example.com   # force IPv4
curl -6 -sSI https://example.com   # force IPv6

If -6 fails, either fix the server's IPv6 binding or remove the AAAA record until it's real. You can see which protocol your own connection uses with our what is my IP page - if you're on IPv4, you'd never notice an IPv6-only outage from your desk.

Is one region or CDN edge failing?

CDNs and anycast networks route each visitor to a nearby edge. When one region's edge, or the route between that edge and your origin, breaks, the site stays up for every other region - including yours. The failure pattern is geographic: reports cluster in one country while your checks pass.

You can't see this from one vantage point, whatever commands you run. It takes probes in multiple places, which is the entire reason multi-region monitoring exists.

The same split can be deliberate. Bot protection that challenges anything that does not look like a browser will fail an uptime check while every human visitor sails through - if that is what you are seeing, allowlist the monitoring probe.

How do I stop relying on user reports?

The uncomfortable summary: your own browser is the least trustworthy witness for this whole class of failure - it shares your DNS cache, your network, and your region. External checks from several places don't. YoPingMe probes your site from two regions you choose out of five locations on three continents, and pages you by email, webhook, or Slack only when both regions agree it's down - a real outage, not a one-network blip. Ten monitors are free, and the first check runs from both your regions while you sign up.