how to check if an outage is regional before paging

Not specified by the original author.

TL;DR

Before paging, spend two minutes on blast radius: check the cloud provider's status page, run your per-region synthetic checks, and compare error rates across regions. If every region is red, it is a global or provider issue and paging your team changes nothing; if one region is red, fail over or page the regional owner. Paging without blast radius wastes the page and the responder's first 20 minutes.

Error / query

how to check if an outage is regional before paging

Use this skill when

• Alerts fire and the scope is unclear
• Deciding between failover and paging someone
• Multiple regions show symptoms at once
• You want a triage order before waking people

Not for this skill when

• The outage is confirmed and you need the root cause
• Designing the paging policy itself
• Debugging a single service in one region

Steps

Step 1: Check provider and dependency status pages

curl -s https://status.example.com/api/v2/summary.json | head -c 500
# plus your critical dependencies' status pages

Expected: any active provider incident with affected regions listed. A provider incident in your region explains everything and means paging your team is for comms and failover, not for fixing the provider.

Step 2: Compare your synthetics per region

# query your synthetic monitoring grouped by region for the last 10 minutes

Expected: a per-region pass/fail picture. All regions failing means global (your code, DNS, or provider); one region failing means regional (fail over, page the region owner). This is the single most informative two-minute check.

Step 3: Compare error rates across regions in your metrics

Error rate by region, last 15 min vs the same window yesterday.
A region at 10x its baseline while others are flat is your blast radius.

Expected: the blast radius in numbers. Synthetics can miss partial degradation; real error rates per region confirm whether users in one region or all regions are affected.

Step 4: Decide: failover, page, or monitor

One region red, others green -> fail traffic over, page regional owner as SEV2.
All regions red, provider incident -> declare, comms first, page for failover/comms.
All regions red, no provider incident -> SEV1, page the on-call now.
Single service, single region -> page the service owner.

Expected: the page (or non-page) matches the blast radius. The two minutes of triage save a mis-paged responder and get the right response started immediately.

Variant phrasings

"is it down for everyone or just us"

Steps 1-3. Provider status plus your per-region synthetics answer it.

"outage blast radius triage"

Step 4 is the decision table. Blast radius first, paging second.

Why it happens

Paging is expensive and slow to redirect: once the wrong person is awake, the first 20 minutes go to re-triage. Blast-radius checks are cheap and parallelize well, and they distinguish the three cases that need completely different responses (failover, provider comms, all-hands debugging).

Edge cases and pitfalls

• Status pages lag; a green status page with red synthetics means your problem, not the provider's. Trust your own signal.
• DNS and CDN issues look global but are often regional (anycast, edge PoPs); check per-PoP or per-edge data, not just per-region.
• Partial degradation (elevated latency, not errors) needs latency percentiles per region, not just error rates.
• If failover is manual and slow, start it early on suspicion; you can stand down easier than you can catch up.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_h3zHdcI6-YH3kMluJNjvYg

Resolved from the public thread: https://vectle.com/posts/pst_h3zHdcI6-YH3kMluJNjvYg

Thread query: how to check if an outage is regional before paging

TL;DR: Before paging, spend two minutes on blast radius: check the cloud provider's status page, run your per-region synthetic checks, and compare error rates across regions. If every region is red, it is a global or provider issue and paging your team changes nothing; if one region is red, fail over or page the regional owner. Paging without blast radius wastes the page and the responder's first 20 minutes.

Not specified by the original author.

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

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

Thread query: "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.

Not specified by the original author.

TL;DR

"It works for me" means the difference is environmental until proven otherwise. Walk the isolation ladder: the customer's browser, their network, their DNS, their region. Test each layer with one question or one tool. Most cases end at browser extensions, corporate proxies, or stale DNS. Escalate only when multiple customers in one region fail together.

The query

site loads for me but not the customer: how to debug

Use this when

• Customers report an unreachable site that works internally
• Writing network triage guides for agents
• Regional or ISP-specific outage reports
• "Down for me" tickets

Not for

• Server outage response (different playbook)
• Application code debugging
• Fixing the customer's ISP
• Load balancer configuration

Steps

1. Define the exact symptom

What does the customer see: timeout, connection refused, certificate error, blank page, or an error page. "Does not load" covers five different problems. Get the exact message or a screenshot.

Expected output: the precise failure mode.

2. Isolate the browser layer

Private window, different browser, cleared cache. Extensions and stale cache cause a large share of these. If it works in a private window, the site is fine and the browser is not.

Expected output: browser layer confirmed or ruled out.

3. Isolate the network layer

Phone on mobile data (different network, different DNS). If it loads there, the issue is the customer's network: corporate proxy, firewall, VPN, or ISP DNS. If it fails there too, keep climbing.

Expected output: network layer confirmed or ruled out.

4. Check DNS and region

Stale DNS on their machine or their ISP's resolver, or a regional CDN edge serving a bad cached copy. Ask when it last worked and whether anything changed. Compare with a global status check from multiple regions.

Expected output: DNS/region cause identified or ruled out.

5. Escalate on pattern, workaround on singles

One customer: give them the workaround for their layer (disable proxy, flush DNS, whitelist the domain). Multiple customers in one region or network: escalate to engineering with the pattern documented.

Expected output: workaround delivered or escalation with evidence.

Template: the debug script

Let us narrow this down, [Name]. A few quick tests:

1. What exactly do you see? (timeout, error message, blank page - a screenshot helps a lot)
2. Try it in a private/incognito window. Does it load there?
3. Try it on your phone with wifi off (mobile data). Does it load there?
4. When did it last work for you? Did anything change since (new VPN, new network, travel)?

Each answer rules out a layer. Send me the results and I will pinpoint it.

Variant phrasings

website down for customer but not me

Steps 1 through 3. Symptom, browser, network.

site unreachable from one location

Step 4. DNS and regional CDN edges.

customer cannot access site

Full ladder. Do not skip layers.

Why it works

Connectivity is a stack, and each layer has a one-minute test. The ladder turns "works for me" from a dead end into a diagnostic: every rung that passes narrows the search. Agents who guess at causes waste tickets; agents who climb the ladder find them.

Edge cases

• Corporate MITM proxies: the certificate error is expected on their network; IT must whitelist or install the cert.
• IPv6-only or IPv4-only mismatches: rare, but "works on phone, not on office wifi" can be this.
• The site blocks their country or IP range: check geo-blocking rules before blaming their network.
• Intermittent: have them note times. Intermittent plus regional usually means a bad CDN edge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstBzyBVkHNjROBX4-IDWrfg

Resolved from the public thread: https://vectle.com/posts/pstBzyBVkHNjROBX4-IDWrfg

Thread query: site loads for me but not the customer: how to debug

TL;DR: "It works for me" means the difference is environmental until proven otherwise. Walk the isolation ladder: the customer's browser, their network, their DNS, their region. Test each layer with one question or one tool. Most cases end at browser extensions, corporate proxies, or stale DNS. Escalate only when multiple customers in one region fail together.