Why Session Replays Belong in Every Bug Report

A screenshot shows you what went wrong. A session replay shows you howit went wrong. When both are included in a bug report, the developer gets a complete picture — the current state of the page, the exact sequence of user actions that led to the issue, and often the root cause visible in the replay's console and network panels.

Most teams already have a session replay tool installed. PostHog, LogRocket, Hotjar, and FullStory are running on millions of websites. But the replay link almost never makes it into the bug report, because the person filing the report does not know how to find it.

The Problem: Replay Tools and Bug Reporters Live in Different Worlds

Here is what typically happens when a QA tester or product manager finds a bug on a site that has session replay:

1. They notice the bug and take a screenshot (maybe)
2. They file a bug report in Jira or GitHub with a description
3. A developer reads the report and cannot reproduce the issue
4. The developer asks: "Can you send me the session replay?"
5. The reporter does not know how to find the replay for their specific session
6. Someone with admin access to PostHog/LogRocket/Hotjar searches for the session by timestamp and user
7. They find the replay, copy the link, and paste it into the issue comment
8. The developer finally watches the replay and understands the bug

This process adds hours or days to the resolution timeline. The replay was there all along — it just was not connected to the bug report.

What Session Replays Add to Bug Reports

Session replays provide context that no other artifact can match:

• Steps to reproduce: Instead of asking the reporter to list what they did, you can watch exactly what happened. Every click, scroll, form input, and navigation.
• Timing and sequence: Was the user clicking rapidly? Did they wait on a loading state for 30 seconds? Did the error happen immediately or after a specific action?
• Console and network: Tools like PostHog and LogRocket capture console errors and network requests alongside the replay. You can see the failed API call that caused the error, right at the moment it happened.
• User frustration signals: Rage clicks, dead clicks, and repeated attempts at the same action are visible in the replay but never described in text reports.
• State that cannot be screenshotted: Hover states, animations, transitions, and timing-dependent behaviors are captured in replays but invisible in static screenshots.

How Automatic Detection Works

The best approach is automatic detection — a bug reporting tool that recognizes when a session replay tool is running on the page and includes the replay link in the report without any manual action.

Here is how each major replay tool can be detected:

PostHog

PostHog exposes its instance on the page, making it possible to retrieve the current session replay URL programmatically. When detected, the replay link points directly to the recording in your PostHog dashboard, timestamped to the moment of the bug report.

LogRocket

LogRocket provides a session URL that can be retrieved from the client-side SDK. The link opens the exact session in the LogRocket dashboard, showing the full user journey up to and including the bug.

Hotjar

Hotjar recordings can be identified by session ID. While Hotjar does not offer a direct deep-link API as easily as PostHog or LogRocket, the session identifier allows developers to locate the specific recording in the Hotjar dashboard.

FullStory

FullStory exposes a session URL through its client-side API. The link opens the session in FullStory with the full user interaction timeline.

The Combined Power: Screenshot + Replay + Errors

The most effective bug report combines three pieces of evidence:

1. Annotated screenshot: Shows the current state of the page with the problem area highlighted. The developer can see immediately what is wrong.
2. Session replay link: Shows how the user arrived at that state. The developer can watch the sequence of events and identify the trigger.
3. Console errors: Shows the underlying technical failure. The developer can see the JavaScript exception, the failed network request, or the warning that points to the root cause.

With all three, the average time to diagnosis drops from hours to minutes. The developer does not need to reproduce the issue — they can see it happen, see the error, and often identify the fix without leaving the issue page.

Real-World Scenario

A user reports that a form submission fails silently — they click submit and nothing happens. With a traditional text report, the developer would need to know: which form, which browser, whether there were validation errors, whether the network request was sent, and what the response was.

With a combined report, the developer sees:

• An annotated screenshot showing the form with the submit button circled
• Console errors showing a TypeError: Cannot read properties of undefined in the form handler
• A session replay link showing that the user filled in all fields, clicked submit, and the button briefly showed a loading state before reverting — with a failed network request visible in the replay's network panel

The developer opens the replay, sees the network request return a 422 with a validation error on a field that the frontend did not validate, and fixes both the frontend validation and the error handling. Total time: 20 minutes from report to fix.

Setting Up Automatic Detection

If you are already using PostHog, LogRocket, Hotjar, or FullStory on your site, Callout automatically detects the running replay tool and includes the session link in every bug report. There is no configuration needed — the widget checks for known replay tool globals on the page and retrieves the current session URL.

This means every bug report your team receives includes a direct link to the relevant session replay, without the reporter knowing or doing anything extra. The developer clicks the link, watches what happened, and starts fixing.

Choosing a Replay Tool

If you are not yet using a session replay tool, here is a quick comparison:

• PostHog — Open source, self-hostable, generous free tier (15,000 sessions/month). Best for teams that want product analytics + replays in one tool.
• LogRocket — Strong focus on frontend monitoring. Good error tracking integration. Free tier available with limited sessions.
• Hotjar — Best known for heatmaps and user feedback alongside replays. Simple setup. Free tier with limited recordings.
• FullStory — Enterprise-grade with strong search and segmentation. Higher price point but powerful for large applications.

Any of these tools paired with a visual bug reporter that auto-detects the replay link creates a powerful debugging workflow.