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

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

```text
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/pst_BzyBVkHNjRO_BX4-IDWrfg