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

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

"The page won't load" is three different problems wearing one sentence: their browser, their network, or your servers. Check your status page first so you never debug a user's laptop during your own outage, then walk the user through cache, DNS, and VPN in that order. The order matters because each step rules out a layer.

The query

"page won't load" support script: cache, DNS, VPN

Use this when

• A page is blank, stuck loading, or times out
• The site loads for you but not the user
• Only one user or office is affected
• The problem started suddenly with no changes
• You are writing the page-load macro

Not for

• Errors that appear after the page loads fine
• Login failures on a working page
• Outages affecting everyone
• Slow pages that do load eventually

Steps

1. Check your status page before touching anything

If your systems are degraded, say so immediately and stop debugging their machine. Nothing burns trust like twenty minutes of cache-clearing during your own incident.

Expected output: outage confirmed or ruled out in under a minute.

2. Get the exact symptom and the exact URL

Blank white page, spinner forever, browser error text, or timeout. Ask them to copy any error text word for word and confirm the URL they used. "It doesn't work" plus a screenshot beats three rounds of guessing.

Expected output: the symptom described precisely, with the URL.

3. Try incognito and a different browser

An incognito window skips cache, cookies, and most extensions in one move. If the page loads there, the problem is their normal browser state, and you go to the cache-clear playbook. If it fails there too, it is network or server.

Expected output: the browser layer confirmed or eliminated.

4. Flush DNS and rule out stale resolution

Have them flush the local DNS cache: on Windows, open Command Prompt and run ipconfig /flushdns; on Mac, restart the browser or reboot. Then retry. Stale DNS sends them to a dead server long after you fixed things.

Expected output: fresh DNS resolution, or the step ruled out.

5. Check VPN, proxy, and corporate filtering

Ask if they are on a VPN or office network, and have them disconnect the VPN or try a phone hotspot. Corporate proxies and VPNs break or block sites constantly, and the fix is on their network side. If the hotspot works, you have your answer.

Expected output: VPN or proxy confirmed as the cause, or ruled out.

Ready-to-use message

Let's narrow this down. First, can you send me a screenshot of
what you see, and confirm the exact page address?

Then try this in order:
1. Open the page in an incognito/private window. If it loads
   there, it's your browser's saved data, and I'll walk you
   through clearing it.
2. If you're on a VPN, disconnect it and retry. Office VPNs
   block sites more often than you'd think.
3. Try your phone's hotspot. If the hotspot works, the issue
   is your office or home network, not our site.

Tell me which step changes things and we'll go from there.

Variant phrasings

website not loading but internet works

Steps 3 through 5. Browser state, then DNS, then the network path.

page stuck on loading spinner

Steps 2 and 3. Pin down whether it is truly stuck or erroring silently, then incognito.

site won't load on office wifi but works at home

Step 5 first. That pattern is the corporate network until proven otherwise.

Why it happens

Loading a page is a chain of about six handoffs: DNS lookup, connection, security check, server response, then the browser assembling the pieces. A failure at any link looks identical to the user, which is a blank page. The script works because it tests each link in order instead of guessing, and the hotspot test is the great divider between "your machine" and "your network."

Edge cases

• Fails in every browser and on hotspot: now it is either your servers or their ISP. Check your status page again and escalate with the evidence trail.
• Only one specific page fails: that page or its data is the problem, not the network. Get the URL and check it yourself.
• Works on wifi but not mobile data, or vice versa: carrier-level filtering or IPv6 quirks. Note the pattern for engineering.
• The user is in a country with heavy filtering: be honest that access may be restricted there, and do not promise workarounds you cannot support.
• Intermittent loading: ask for timestamps of failures. Patterns in time point at server load or scheduled jobs, not the user's setup.

Provenance

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

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

Thread query: "page won't load" support script: cache, DNS, VPN

TL;DR: "The page won't load" is three different problems wearing one sentence: their browser, their network, or your servers. Check your status page first so you never debug a user's laptop during your own outage, then walk the user through cache, DNS, and VPN in that order. The order matters because each step rules out a layer.

Not specified by the original author.

TL;DR

"Slow" is not a measurement, so your first job on a live call is turning it into seconds. Then split the problem three ways: their machine, their network, your servers, using tests the user can run while you wait. Never start debugging before you know which third is slow, because the fixes are completely different.

The query

how to troubleshoot slow page loads with a user live

Use this when

• A user reports slowness while you are talking to them
• Page loads are intermittently slow
• One user is slow while others are fine
• You are training agents on live triage
• A ticket says "slow" with no numbers attached

Not for

• Pages that never load at all
• Outages affecting everyone
• Backend performance optimization
• Slow file uploads or downloads

Steps

1. Turn "slow" into seconds

Ask them to time it: open the page, count the seconds until it is usable. Also ask whether it is every page or one page, and whether it is always slow or comes and goes. Write the numbers down, because "slow" will drift during the call otherwise.

Expected output: a number in seconds, a scope, and a pattern.

2. Test a different page and a different site

Have them load a simple page in your app, then a big external site. If everything is slow, it is their machine or network. If only your app is slow, it is you or the route between you. If only one page is slow, it is that page's data.

Expected output: the slowness scoped to machine, network, app, or page.

3. Rule out the browser in one move

Incognito window, same page, time it again. If incognito is fast, an extension or a bloated cache is the drag. If it is equally slow, the browser is innocent and you move on without wasting ten minutes on settings.

Expected output: browser layer confirmed or eliminated.

4. Test the network while they wait

Have them try a phone hotspot, or disconnect the VPN. Time the same page on each. A page that loads in 3 seconds on hotspot and 30 on office wifi is a network story, full stop, and no amount of app debugging will fix it.

Expected output: network confirmed as the cause, or ruled out live.

5. Capture the evidence for engineering

If it points at your side, grab the essentials before hanging up: the exact URL, the timed seconds, their location and network, a screenshot of the slow state, and whether it reproduces in incognito. That bundle is what turns a vague ticket into an actionable one.

Expected output: a ticket engineering can actually reproduce from.

Ready-to-use live script

Let's measure this together so we're not guessing. Can you:

1. Open the slow page and count the seconds until you can
   actually use it. Tell me the number.
2. Now open the same page in an incognito window and time
   it again.
3. If you're on VPN, disconnect it and try once more.

Tell me all three numbers. That'll tell us whether it's your
browser, your network, or our side, and then we'll know
exactly what to fix.

Variant phrasings

app is running slow today

Steps 1 and 2. Numbers first, then scope it to machine versus app.

page takes forever to load support

Steps 1 through 4 in order. Do not skip the hotspot test.

intermittent slowness troubleshooting

Steps 1 and 5. With intermittent issues, timestamps and patterns matter more than live tests.

Why it happens

Slowness is the sum of every link in the chain: the device rendering, the network carrying, the server answering, the page's own weight. Users feel one sensation, slowness, but the causes live in different worlds with different owners. The live triage works because each test removes one world, and the numbers keep everyone honest about what "fixed" means.

Edge cases

• Slow only at certain hours: that is load, either yours or their network's. Ask for the times and compare against your traffic patterns.
• Slow only with large datasets: the page is fine, the data volume is the problem. Check pagination and filters rather than the network.
• Old device, everything slow: be honest that the hardware is the bottleneck. No triage step fixes a ten-year-old laptop.
• User insists it is your servers with no evidence: run the tests anyway and show the numbers. Data ends the argument kindly.
• Slowness after a deploy: check your release timeline first. New code is the prime suspect when the timing lines up.

Provenance

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

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

Thread query: how to troubleshoot slow page loads with a user live

TL;DR: "Slow" is not a measurement, so your first job on a live call is turning it into seconds. Then split the problem three ways: their machine, their network, your servers, using tests the user can run while you wait. Never start debugging before you know which third is slow, because the fixes are completely different.