All posts

The Bug No One Can Reproduce: Using Breadcrumbs and Session Replay to Debug the Invisible

When a user reports a bug you can't reproduce, breadcrumbs and session replay give you the context you need to find and fix it.

"Works on My Machine"

A user reports: "I click the submit button and nothing happens." You try it. It works perfectly. You try on their browser. It works. You try on mobile. It works. You check the logs. Nothing. The error tracking dashboard shows no errors.

This is the most frustrating category of bugs: the ones that happen in production but refuse to reproduce in development. They account for roughly 30% of all bug reports, and they consume a disproportionate amount of engineering time.

Why Some Bugs Won't Reproduce

Production bugs that can't be reproduced locally usually fall into these categories:

1. State-Dependent Bugs

The user has data in their account that you don't. Maybe they have 10,000 items in a list that triggers a pagination edge case, or their profile has special characters that break a regex.

2. Sequence-Dependent Bugs

The user did things in a specific order: opened tab A, switched to tab B, went back to tab A, and now the state is corrupted. You'd never think to test that sequence.

3. Timing-Dependent Bugs

A race condition between a network request and a user action. The API responded slowly, the user clicked before data loaded, and the component rendered in an unexpected state.

4. Environment-Dependent Bugs

Their browser has an ad blocker that strips a script tag. Their company proxy modifies response headers. Their phone has low memory that forces a garbage collection at the wrong moment.

Breadcrumbs: The Error's Black Box

Breadcrumbs are a chronological log of events that happened before an error occurred — like a flight recorder for your application. A typical breadcrumb trail looks like:

14:23:01 [http]       GET /api/user/profile → 200 (45ms)
14:23:02 [ui]         Click: button#save-settings
14:23:02 [http]       POST /api/settings → 200 (120ms)
14:23:03 [navigation] /settings → /dashboard
14:23:03 [http]       GET /api/dashboard/data → 200 (89ms)
14:23:04 [ui]         Click: button#export-report
14:23:04 [http]       POST /api/export → 500 (2340ms)
14:23:04 [error]      TypeError: Cannot read properties of undefined

From this trail, you can see: the user saved settings, navigated to dashboard, clicked export, the export endpoint returned 500, and then the frontend crashed. The bug is the unhandled 500 response from /api/export — something you'd never find from the stack trace alone.

What Good Breadcrumbs Capture

Most SDKs capture breadcrumbs automatically:

  • HTTP requests — URL, method, status code, duration
  • UI events — clicks, form inputs, navigation
  • Console outputconsole.log, console.error messages
  • Navigation — page/route changes

The best error tracking tools display these as a visual timeline on the issue detail page.

Session Replay: See What the User Saw

When breadcrumbs aren't enough, session replay lets you watch a video-like recording of the user's browser session. You see exactly what they saw: the page layout, the click that didn't work, the loading spinner that hung.

Session replay is particularly valuable for:

  • "Nothing happens" bugs — you can see if the button was actually clicked, or if a modal was blocking it
  • Layout bugs — the user's screen resolution causes an element to overlap the button
  • Timing bugs — you can see the user clicked before the loading state completed

Privacy Considerations

Modern session replay tools mask sensitive data by default:

  • Input fields show **** instead of actual text
  • Credit card forms are completely hidden
  • You can configure additional selectors to mask

A Practical Debugging Workflow

When a user reports a bug you can't reproduce:

Step 1: Check the Error Dashboard

Search for errors around the time the user reported the issue. Even if they said "nothing happened," there might be a swallowed error or a failed API call.

Step 2: Read the Breadcrumbs

If you find a related error, read the breadcrumb trail. What did the user do in the 30 seconds before the error? This often reveals the reproduction steps.

Step 3: Watch the Session Replay

If breadcrumbs aren't enough, find the user's session replay. Watch the 60 seconds before the bug. You'll often have an "aha!" moment when you see something unexpected in their environment.

Step 4: Check Environment Tags

Look at the error's tags: browser version, OS, screen resolution, device type. If the bug only happens on Safari mobile, you've narrowed your search significantly.

Step 5: Reproduce with Constraints

Using what you learned from breadcrumbs and replay, reproduce locally with the same constraints: same browser, same data state, same click sequence.

The Investment

Breadcrumbs are essentially free — most SDKs capture them automatically. Session replay requires additional SDK configuration and storage. But the time savings are significant: instead of spending 4 hours guessing at reproduction steps, you spend 10 minutes watching a replay.

For bugs that "no one can reproduce," breadcrumbs and session replay aren't nice-to-haves. They're the difference between a 4-hour investigation and a 10-minute fix.

Try Bugsly Free

AI-powered error tracking that explains your bugs. Set up in 2 minutes, free forever for small projects.

Get Started Free