← All posts

Why Your Support Team Can't Reproduce the Bug (And How to Fix It)

· hint.dev team debugging customer-support engineering saas bug-reproduction

"I can't reproduce it" is the most expensive sentence in SaaS support. It ends the investigation before it starts, sends the customer back to document more steps, and leaves a real bug alive in your production system.

This post explains why reproduction fails so often and what modern SaaS teams are doing to fix it.

The Reproduction Gap

Reproduction fails because of a fundamental mismatch between the environment where the bug occurred and the environment where you're trying to re-create it.

When a customer reports a bug, they're describing what they saw — not what caused it. The causal chain often involves:

  • Session state that's long since expired (OAuth tokens, cached API responses, feature flags served at that moment)
  • Data state that's specific to their account (edge-case subscription tier, a 3-year-old record with a malformed field)
  • Timing that's hard to recreate (a race condition between two async calls, a network timeout at exactly the wrong moment)
  • Browser or OS context the customer doesn't think to mention (an extension that modifies the DOM, a corporate proxy that strips headers)

Ask anyone to reproduce that in a fresh dev environment from a Loom video and a paragraph of prose. They can't. Not reliably.

Why the Standard Playbook Fails

Most support teams respond to "can't reproduce" with one of three approaches:

Approach 1: Ask for more information

"Can you send us the exact steps? What browser are you on? Can you open DevTools and take a screenshot of the console?"

This works occasionally for simple bugs. For state-dependent issues it's nearly useless — you're asking the customer to describe a moment that's already passed, and most customers don't have the technical context to describe the right things.

Approach 2: Add more logging

Deploy a new version with more instrumentation, wait for the bug to happen again, then look at the logs.

This works, eventually. The cost is measured in deploys, wait time, and the customer's patience. For rare edge cases you might be waiting weeks.

Approach 3: Give up and close the ticket as "cannot reproduce"

This is more common than most teams admit. If you close enough low-priority tickets as "cannot reproduce," you end up with a product that silently fails for a meaningful percentage of users — they just don't report it a second time. They churn instead.

The Root Fix: See What the Customer Saw

The reproduction gap exists because support teams work from descriptions of bugs, not from the bugs themselves. The fix is to eliminate the description step.

This is what hint.dev is built for. When a customer reports an issue, instead of starting a description thread, you join their live session and see their actual application state. The session is yours to navigate — you can click around their UI, open the console, inspect the network tab — exactly as if you were sitting at their computer.

For bugs that "can't be reproduced," this changes everything:

  • If the bug is still present (a broken UI component, a permission error), you see it immediately.
  • If it was a one-time state issue, you can see the current state and often work backward to what went wrong.
  • If it's data-specific, you can inspect the account state with the customer present — they confirm what they're seeing, you confirm what you're seeing, and you find the divergence.

A Practical Example

Here's what "cannot reproduce" typically looks like before and after:

Before: Customer: "The export button doesn't work for me." Support: "Can you describe the steps?" Customer: "I click Export, the spinner appears, then nothing." Support: "What browser? What export type? Are you on the free or paid plan?" (3 days and 8 messages later) Support: "We can't reproduce this. Can you try again?" Customer: (churns quietly)

After: Customer: "The export button doesn't work for me." Support: (joins live session, sees the spinner, opens network tab, finds a 502 from the third-party PDF renderer, adds a 30-second timeout to the job queue) Support: "We found it — a timeout in our PDF renderer. Deploying a fix now, should work in ~5 minutes." Customer: (becomes a case study)

The bug was always there. The difference is whether you could see it.

Building a Reproduction-First Support Culture

Shifting to live-session support requires two changes: tooling and habit.

Tooling

The hint.dev SDK instruments your app so every user session is joinable from your support dashboard. Setup is a one-time integration — wrap your app with the provider, pass a session identifier, and every authenticated session becomes visible to your support team.

import { HintProvider } from '@hint.dev/sdk';

<HintProvider sessionId={user.id} projectId="your-project">
  <App />
</HintProvider>

When a customer reports an issue, you click "Join Session" in the hint.dev dashboard. No Zoom call, no screen share, no asking them to install anything.

Habit

The habit shift is: default to joining a session before asking any questions.

Instead of starting with "can you describe what you're seeing," start with "can I take a look at your account?" In most cases, 60 seconds of live observation answers all the questions you would have spent three emails asking.

This also sends a signal to customers that you take their issues seriously. "The engineer joined my session and found the bug in two minutes" is the kind of support story that gets shared.

When You Genuinely Can't See It Live

Some bugs are truly ephemeral — they depend on a network condition or timing that won't occur while you're watching. For these:

  1. Ask for console log exports directly in the hint.dev session (no need to explain DevTools to a non-technical user — you can read it yourself).
  2. Check recent session replays for the account — hint.dev keeps a rolling window of session activity so you can review what happened just before the report came in.
  3. Add targeted telemetry for the specific condition and wait for recurrence — but now you're waiting for data you've precisely specified, not hoping for a reproduction.

The Metric to Watch

If you implement live-session support, track your reproduction rate: the percentage of reported bugs where you can confirm the actual error condition. Healthy teams see 85–95%. Email-only support teams typically see 35–50%.

The gap between those numbers is your backlog of silent churn.

Start Here

If you have an active bug you can't reproduce right now, install the hint.dev SDK and try joining the next customer session that reports it. The installation takes about 20 minutes. The first reproduction takes about 2.

For more on the support workflow side, see How to Debug Customer Issues Without a 20-Email Thread.