Reproducing the unreproducible

The most common — and most frustrating — situation in technical support: a customer reports a bug, and it simply will not reproduce. Not in staging. Not on your machine. Not even on theirs, an hour later. The ticket sits there, mocking everyone.

At AZA Finance, a payments and FX platform, being the first responder on customer-reported issues meant this situation was my Tuesday. I was the direct technical point of contact for customers and integration partners during support calls — resolving issues in real time, with no staging environment safe to hide behind.

A session that refused to escalate

My favourite example: a customer lost front-end access shortly after onboarding. Every signal said “escalate” — they’d completed onboarding a week earlier, nothing had changed on our side, and login issues are nobody’s favourite. Instead of passing it on, I worked through the layers: browser, network, credentials — and found the cause somewhere nobody checks. A personal firewall on the customer’s own machine was blocking the application. Resolved directly, in one session, no engineering time spent.

“Cannot reproduce” is almost never a mystery. It’s a missing observation. The bug happened once, which means the conditions existed once — you just weren’t measuring them.

What actually works on these calls

  • Rule out the cheap causes first, out loud, with the customer on the line. It’s faster for you to check their environment step by step than for them to describe it to someone new tomorrow.
  • Read the error’s shape, not just its text. Recurring server errors, timeouts, auth rejections — the pattern of failure usually tells you which layer owns the problem. That’s how you know a config issue from a backend bug, and whether you can resolve it yourself or genuinely need to escalate.
  • Walk the real flow live. Screen-sharing through the customer’s actual integration — request by request, step by step — surfaces the missed step that neither the docs nor a ticket would ever reveal.
  • Compare against what changed. Recent release? Config change? Their environment? Git and deployment records narrow the search space faster than any amount of staring.
  • Know your own limits. If the remaining question genuinely lives on our side of the fence, escalate — with a clean repro and everything you’ve ruled out. Rescuing an issue doesn’t mean hoarding it.

The payoff goes beyond the ticket. The same observation habits — structured logging, monitoring tuned to the customer’s actual failure mode — start catching anomalies before customers do. And a support engineer who reads logs and APIs as fluently as code doesn’t just close tickets faster. Sometimes the ticket never gets written.