## 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

```text
"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.

```bash
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.

```bash
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.

```bash
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".

```bash
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