is it down for everyone" triage order

TL;DR

Check your own network first, then the status page, then a second network, then external monitors. That order rules out your machine before you declare a global outage. Triage direction matters: outside-in is faster and cheaper than paging twelve engineers for a VPN blip.

Error / query

"is it down for everyone" triage order

Someone reports an outage and nobody knows the blast radius. You need an answer in minutes, not a war room.

Use this skill when

• users report an outage and you dont know the blast radius
• you need to confirm or deny a global outage quickly
• an alert fired but the symptoms are vague
• someone asks "is it down for everyone" in chat and nobody has an answer

Not for this skill when

• the cause is already identified (skip triage, work the incident)
• you need a formal root cause analysis or postmortem (different skill)
• youre comparing monitoring vendors (a buying question, not triage)

Steps

1. Rule out your own machine and network

Check whether the problem is your connection before anything else. A VPN hiccup looks exactly like an outage from one desk.

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/health

Expected: HTTP 200 with a fast time means your network is fine. A timeout or connection error means the problem may be local to you, so fix that before paging anyone.

2. Check your status page and recent deploys

Look at the status page and the deploy log. Most "is it down" answers live in one of these two places.

git log --oneline -5

Expected: you either see a deploy that lines up with the outage window (prime suspect) or you can rule deploys out and keep going.

3. Test from a second network, not your laptop

SSH into a bastion or cloud host in another region and hit the service from there. One vantage point is an anecdote; two is the start of data.

ssh [user]@[bastion-host] "curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://YOUR-service-url/health"

Expected: HTTP 200 from the bastion while your laptop fails means your network is the problem, not an outage. Failure from both means it is real; start the incident process.

4. Confirm with multi-location monitors before paging

Check your uptime monitor's multi-region results. They are the ground truth for "everyone".

for region in us eu asia; do
  ssh [user]@[bastion-$region] "curl -s -o /dev/null -w '%{http_code}\n' https://YOUR-service-url/health" &
done
wait

Expected: results from three regions. Agreement in either direction means the answer is solid; mixed results mean a partial outage, which changes the response.

Variant phrasings

how to check if a website is down for everyone

Same fix: the outside-in order in steps 1 through 4 applies to any site, not just your own services.

outage triage checklist

Same fix: this triage order IS the checklist. Pin it in the incident channel so anyone can run it without waiting for the on-call.

is the outage global or just me

Same fix: step 1 (your network) and step 3 (a second network) draw that line in under two minutes.

Why it happens

"Is it down for everyone" gets asked in chaos, and people answer from their own screen. Without an ordered check, one persons VPN problem becomes a SEV1 page for the whole team. The order exists to kill local causes first, because they are the cheapest to test and the most common.

Edge cases and pitfalls

• Partial outages: one region down, others fine. The multi-location check in step 4 catches these.
• Status page hosted on the same infra as the product: it goes down with the outage. The external monitors stay authoritative.
• DNS issues look global from one resolver. Re-check with a public resolver before concluding.
• Dont ask "is it down for everyone" in a 200-person channel. Run the checks, then post the result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EM1HHbqLimd6s885sUq92Q