how to reproduce a customer issue you can't see

Not specified by the original author.

TL;DR

You cant reproduce it because your setup isnt their setup. Close the gap methodically: get the exact environment, watch a recording of it happening, rebuild their conditions on your side, and use logs and timestamps where your eyes cant go. Most "cant reproduce" bugs are environment mismatches, not mysteries.

The query

how to reproduce a customer issue you can't see

Use this when

• The bug wont reproduce on your machine
• The customer insists it happens every time
• The issue seems environment-specific
• You need evidence before escalating

Not for

• Writing the engineering escalation itself
• General first-response troubleshooting
• Issues you can already reproduce
• Outages (those skip straight to escalation)

Steps

1. Get the exact environment, not the approximate one

Browser and version, OS, app version, account type, and what was on screen. "Chrome" is not an environment; "Chrome 126 on Windows 11, Pro account, with the browser zoomed to 125%" is. Ask for specifics, dont accept vibes.

Expected output: a complete environment snapshot from the customer.

2. Ask for a recording of it happening

A screen recording beats ten paragraphs of description. Ask the customer to record from a fresh load through the failure, narrating what they click. Most customers will do this if you ask plainly.

Expected output: a video showing the exact sequence that triggers the issue.

3. Rebuild their conditions on your side

Match the environment from step 1 as closely as you can: same account type, same data shape, same settings. Test accounts, staging, and browser profiles exist for exactly this. The bug usually appears the moment your setup matches theirs.

Expected output: a test setup that mirrors the customer's as closely as possible.

4. Follow the recording click by click

Replay their exact sequence in your rebuilt environment, including the boring steps they think dont matter. The step they skipped in the written description is usually in the video.

Expected output: either a reproduction or a precise list of where your attempt diverged.

5. Use logs and timestamps to see what you cant

When your eyes still cant see it, pull server logs, error timestamps, and session data around the moment it happened. Correlate the customer's "about 2:30" with actual events. Logs reproduce what screens cant.

Expected output: a timestamped trail showing what happened server-side during the failure.

Variant phrasings

how to debug a customer issue remotely

Steps 2 and 5. The recording shows you the client side; the logs show you the server side.

customer bug wont reproduce what to do

Steps 1 and 3. Nine times out of ten the environment doesnt match.

reproducing environment-specific bugs in support

Steps 3 and 4. Rebuild, then replay exactly.

Why it happens

Support machines are clean, updated, and well-configured. Customer machines are not. The gap between those two realities is where unreproducible bugs live: old browser versions, unusual settings, specific data shapes, corporate network proxies. Reproduction is just closing that gap one variable at a time.

Edge cases

• The customer cant or wont record: walk them through it live on a call, screensharing. Slower, but the same principle.
• It only happens with their data URIs ask for a sanitized export, or reproduce with a test account loaded with similar data.
• Intermittent issues: dont chase a single reproduction. Document the pattern (time, frequency, conditions) and escalate with that.
• The issue is on a device you dont have: borrow it, use a device lab, or ask the customer for the exact model and OS version for the escalation.
• You reproduced it but the customer cant anymore: it may be fixed or data-dependent. Note the version where you saw it and keep the ticket open one cycle.

Provenance

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

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

Thread query: how to reproduce a customer issue you can't see

TL;DR: You cant reproduce it because your setup isnt their setup. Close the gap methodically: get the exact environment, watch a recording of it happening, rebuild their conditions on your side, and use logs and timestamps where your eyes cant go. Most "cant reproduce" bugs are environment mismatches, not mysteries.

Not specified by the original author.

TL;DR

Dont try to make staging behave like prod by guessing. Write down the exact production context for one failing case, list every way prod differs from staging, and eliminate the differences one at a time until the bug shows up. Production-only bugs are always a difference you havent found yet, and the repro runbook below is how you find it.

The query

how to reproduce a bug that only happens in production

Use this when

• A ticket comes back "cannot reproduce" but customers keep hitting it
• Staging is green and production is red for the same code
• An agent needs a repro before engineering will take the escalation
• The bug is intermittent and you suspect data, timing, or config

Not for

• Bugs you can already reproduce locally
• Performance or load testing
• Deciding whether a bug is worth fixing
• Writing the fix itself

Steps

1. Freeze one failing case in writing

Pick a single incident, not the general complaint. Record the account, plan tier, request path, timestamp, region, feature flag states, and the exact error text. One case gives you something to chase; the general complaint gives you nothing.

Expected output: a one-paragraph incident snapshot at the top of the ticket.

2. List every way prod differs from staging

Data volume and shape, real user input vs fixtures, flag values, third-party responses, cron timing, traffic mix, cache warmth, region. Most production-only bugs live in this list.

Expected output: a written difference list with at least five entries.

3. Replay with production-like input, not your fixtures

Rebuild the failing case using an anonymized production record or request payload for that exact account. Fixtures are built from assumptions; production input carries the thing your assumptions missed.

Expected output: a replay attempt using real-shaped input, logged with its result.

4. Instrument the path instead of guessing

Add temporary logging or tracing around the failing path in a staging or canary environment: what value entered, what branch ran, what the third party returned. Remove it after. One instrumented run beats ten theories.

Expected output: log lines that show the exact divergence point.

5. Mirror prod config in your repro environment

Set the same flags, the same limits, the same integrations to the same sandbox endpoints. A bug that needs flag X on and data shape Y will never appear in an environment that has neither.

Expected output: a checklist showing which prod settings are now mirrored.

6. Lock the repro into a regression test

Once it reproduces, write the automated test before the fix. The test proves the repro and protects it forever. A repro that only exists in a chat thread will regress within a year.

Expected output: a failing test in the suite that captures this exact case.

Repro runbook template

Bug: [one-line summary]
First seen: [date, ticket links]
Failing case: [account or identifier, plan, region, timestamp]
Error text: [paste the exact error]
Prod context: [flag states, data shape, third party involved]
Differences from staging:
1. [e.g. real user payloads, not fixtures]
2. [e.g. flag checkout_v2 is ON in prod]
3. [e.g. cron runs every 5 min in prod, hourly in staging]
Hypotheses (testable, one at a time):
1. [hypothesis], test it by: [how you will test it]
2. [hypothesis], test it by: [how you will test it]
Repro attempts:
- [date] [what you tried] then [result]
Repro confirmed: [yes/no, date, test location]

Variant phrasings

cant reproduce a bug that only happens in prod

Steps 1 through 3 are the whole answer. Support agents usually skip the failing-case snapshot and jump to theorizing; the snapshot is what makes the rest work.

how to debug production-only errors as a support agent

Your job is steps 1 and 2: freeze the case and list the differences. That alone turns an escalation engineering ignores into one they can act on.

staging works but production fails

That sentence is the difference list in disguise. Write the list down instead of saying it.

Why it happens

Production differs from every other environment in dozens of small ways at once: real input shapes, real volumes, real timing, real third-party behavior, flags that were flipped for one cohort. Locally reproducible bugs are usually logic errors; production-only bugs are usually context errors, the code is fine in a context that never exists in prod. Reproducing is just hunting the context difference.

Edge cases

• Bugs that need real user input: anonymize carefully. Keep the shape of the input (length, encoding, nesting) and strip the content. Shape is usually what matters.
• Time-based bugs: check cron schedules, timezone handling, and daylight-saving transitions. These reproduce only when the clock cooperates.
• Third-party flakiness: record the exact third-party response in the failing case. If you cant capture it, mock the recorded failure response in staging.
• Multi-tenant bugs: the failing case may need the account's full state (plan history, entitlements), not just the failing request.
• One-off prod incidents: sometimes you truly cant reproduce. Say so explicitly, ship the monitoring from step 4 permanently, and close the loop on the next occurrence.

Provenance

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

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

Thread query: how to reproduce a bug that only happens in production

TL;DR: Dont try to make staging behave like prod by guessing. Write down the exact production context for one failing case, list every way prod differs from staging, and eliminate the differences one at a time until the bug shows up. Production-only bugs are always a difference you havent found yet, and the repro runbook below is how you find it.

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.