Can a PostHog Bug-Report Survey Auto-Link to the Session Recording?
No, not as a dedicated feature. PostHog has a survey product and a session replay product, and they don't hand you a "bug report" question type that automatically drops the matching recording into the response row. PostHog's own engineering team scoped exactly that, a bug-report question including a session ID, a connection to the screen recording, and a Slack notification, back when surveys were first built, and it's been sitting in the Surveys Megaissue on GitHub under "Nice-to-have's, side quests for sprints" ever since. The tracking issue itself is closed, but that specific checkbox was never ticked off.
What you get instead is looser. Survey responses land in PostHog as regular events, and regular events inherit whatever session context PostHog was already capturing, including replay. That's a real path to the recording, just not a button anyone built for it. The response is one event among several, and the recording that proves it out is a separate lookup PostHog leaves to you. Below is what PostHog's docs actually confirm, the manual route that works today, and the point past which manual stops being reasonable.
What PostHog's roadmap actually said
The "bug report question type" line item is specific enough to quote in full, since it names the exact feature this guide's title is asking about. In the megaissue's own words, "Bug report question type: Includes session ID, connection to screen recording they also have in PostHog, sends Slack notification." It sat in the megaissue's third tier of five, "Nice-to-have's, side quests for sprints," ranked below High priority and Quick wins but above two lower tiers reserved for deferred and abandoned work, and it was never checked off before the tracking issue closed. Nothing since has replaced it with a shipped feature. Today's survey creation docs list freeform text, link, rating (emoji and number), single choice, and multiple choice as the available question types. There's no bug-report type among them, and no field for a recording link.
Why the general mechanism gets you partway there anyway
PostHog's own survey product page explains why a workaround exists at all, noting that "because responses land as events, every answer carries the respondent's session replay, events, and person properties." That's true because of how session identity works everywhere in PostHog, not because of anything survey-specific. PostHog's web and mobile SDKs stamp a $session_id on every captured event, survey responses included, and a new session only starts after 30 minutes of inactivity or a 24-hour cap, per the sessions documentation. So the survey response event and the recording it happened inside share the same session ID by default. The data is there. What's missing is a UI element that reads that shared ID and shows you the recording without you asking for it by name.
The manual route that works today
Two paths get you to the recording, and neither is one click from the response itself:
- Through the person profile. PostHog's Slack destination for survey notifications, set up under a survey's Notifications tab, can include a button linking to the respondent's person profile alongside the response text, per the destinations documentation. Open that profile and its Recordings tab, then find the session nearest the response timestamp.
- Through a Session Replay filter. The Replay page supports saved filters on events, properties, console logs, and feature flags, according to PostHog's guide to watching recordings. Filter for the
survey sentevent against your bug-report survey's ID, and every recording that contains a matching submission shows up in the list.
Either way, you're trading a one-click feature for a two-hop lookup. Response to profile to recording, or response to filtered replay list to recording. It works. It's also a lookup a person has to run, per bug report, every time.
Priya's four-minute lookup, and the report that came back
Loft & Line builds class-booking software for boutique fitness studios, and its in-app "something's wrong" survey is a single freeform text box triggered from the account menu. Priya Chandrasekaran, who leads engineering there, started getting complaints about the booking calendar freezing whenever a member tried to reschedule a class into a slot that had just opened up.
Support ticket, forwarded to Priya: A member at Ridgeline Fitness says the calendar locks up every time she tries to move her Tuesday class. Happened twice this week.
The survey response that matched it said, "tried to switch classes, screen froze, had to close the app." No stack trace, no repro steps, just a stuck screen and a killed session. Priya pulled up the response, copied the respondent's distinct ID, opened their PostHog person profile, and checked the Recordings tab for anything near the submission timestamp. The recording caught what the text couldn't. It showed the member tapping "reschedule" twice in quick succession while the first request was still in flight, and the app rendering two conflicting calendar states at once. Priya filed the fix that afternoon with the recording linked directly in the issue.
That one lookup took about four minutes. It also only worked because Priya already had the distinct ID in hand and the member had been identified before she filed the report. The next week, three more freeform responses came in describing the same freeze in three different ways, one from a member on the web app instead of mobile, none of them tagged as related, and Priya didn't connect them to the fix already shipped until a fourth report came in through Zendesk asking why the bug was back.
Four minutes per report doesn't scale forever
The person-profile and replay-filter routes both hold up for the volume of bug reports a small team gets in a week. They stop holding up for predictable reasons:
- It's a per-response lookup. Each report means copying an ID, opening a profile or a filter, and watching a recording, one at a time. Ten reports a week is fine. Forty is a job.
- It depends on identify() being called before the survey fires. If the respondent hasn't been identified yet, the person profile step dead-ends at an anonymous distinct ID with nothing useful attached, the same identity gap covered in how to see who actually submitted a PostHog survey response.
- Nothing here groups repeat reports of the same bug. Three phrasings of the same booking-calendar freeze look like three unrelated rows in the survey results table. Recognizing they're the same underlying issue, and that it's the same bug that shipped a fix a week earlier, is a judgment call someone has to make by memory.
- A Slack notification per response adds noise without adding grouping. Pointing the survey at a busy channel, the same pattern covered in stopping PostHog survey Slack notifications from drowning your channel, gets you visibility into each report landing, not a count of how many are the same thing.
That third point is the one Loft & Line actually hit. The recording answered "what happened" every time. Nothing in PostHog answered "have we seen this exact freeze before, and did we already ship a fix for it."
We build Modem, so it's worth being precise about what it would and wouldn't have caught here, rather than treating it as a fix for everything above. Modem's PostHog integration reads product analytics, feature flags, experiments, and error tracking. It doesn't ingest survey responses or session recordings, so the three freeform survey answers describing the same booking-calendar freeze would have stayed just as invisible to it as they did to Priya the first time around. What Modem does watch is Slack, support tickets, and sales call notes, which means the report that reached Zendesk, the fourth one, would have been the one it caught, matched against the Linear issue Priya had already filed instead of starting a fresh search for whether the bug had shown up before. That closes part of the gap this example shows, not the whole thing. Pricing is unlimited users on every plan, with usage-based volume beyond what's included, not a per-seat charge for however many bug reports a team happens to file. Modem doesn't watch the recording for you. It keeps track of who's hit the bug once someone has.
Two things to check before the next report
If your bug-report survey doesn't have a Slack notification with a person-profile button yet, add one under the survey's Notifications tab. If it does, build a saved Replay filter for its survey sent event too, so you have a second route in when identify() hasn't run yet. Neither fix groups repeat reports on its own. That part still depends on someone remembering the last freeze looked the same.
