site loads for me but not the customer: how to debug
How to debug when a site loads for support but not the customer: the isolation ladder from customer environment up to CDN and DNS. Use when customers report unreachable sites that work internally, or when writing network triage guides. Not for server outage response, code debugging, or ISP issues beyond diagnosis.
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 debugUse 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