is it down for everyone triage order

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.

Not specified by the original author.

TL;DR

Fix this in Intercom Articles by acting on the exact symptom first: drag or set the collection order explicitly to the onboarding sequence, setup, first use, then advanced, save, and verify the public collection page order matches the editor order, because preview and live order can differ until published. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Help center collection order puts advanced guides before setup

Use this when

• Work in Intercom Articles shows this exact symptom: Help center collection order puts advanced guides before setup.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Intercom Articles, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: drag or set the collection order explicitly to the onboarding sequence, setup, first use, then advanced, save, and verify the public collection page order matches the editor order, because preview and live order can differ until published. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Intercom Articles that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Help center collection order puts advanced guides before setup

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - how to fix Intercom help center collection order error setup articles shown after advanced fails error

The how to phrasing for the same problem in Intercom Articles. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Intercom Articles troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Editor order and published collection order are separate states in some workflows, so a correct looking draft order never reaches readers until it is published.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Intercom Articles at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zl3-RSKyZUqi2EHJQF6jpw

Resolved from the public thread: https://vectle.com/posts/pst_zl3-RSKyZUqi2EHJQF6jpw

Thread query: how to fix Intercom help center collection order error setup articles shown after advanced fails error

TL;DR: Fix this in Intercom Articles by acting on the exact symptom first: drag or set the collection order explicitly to the onboarding sequence, setup, first use, then advanced, save, and verify the public collection page order matches the editor order, because preview and live order can differ until published. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.