How to tell if a PostHog rage click is the same bug as an open support ticket
Nothing in PostHog checks your ticket queue, so the two systems never confirm the match for you. PostHog fires a $rageclick event and drops the recording into a list; your ticket system has a customer's own words. Telling whether they're the same bug means finding one thing they both carry, usually who the person is and roughly when it happened, and reading the recording against what the ticket actually says.
That's a manual cross-reference, not a feature either tool ships. PostHog's session replay has no field for "linked ticket," and most support tools have no field for "linked session recording." Below is the identifier that actually bridges the two, how to pull it fast, and the point past which doing this by hand for every rage click stops being a reasonable use of anyone's morning.
The claim button that turned out to be two different bugs
Dockline builds a tracking portal for small freight brokers, and one screen lets a shipper file a damage claim straight from a delivered shipment's page. Klara Munro runs support there.
Ticket #5820, from a shipper: The "File a claim" button on our delivered load doesn't do anything. I've clicked it four times now.
Klara pulls up the shipment's account in PostHog and filters the person's recordings for the $rageclick event on the claims page. One session lines up, four minutes before the ticket landed. Three clicks on the button, no network request firing, no modal opening. She comments on the recording, "matches ticket #5820, same shipper," and pings Anton Reidel, the engineer on call.
Klara: Found the session, matches the ticket almost to the minute. Left a note on it.
Anton: That's not our claims bug, though. I fixed a stuck-submit issue on that button last week. This one's a permissions check failing silently for accounts added after a shipment already shipped. Different root cause, same three clicks.
The rage click and the ticket were the same customer, the same button, the same four-minute window, and still not the same bug Anton expected. Watching the recording is what caught it. He filed a new issue instead of reopening the old one, and Klara replied to the shipper with an actual timeline instead of "should already be fixed."
That match ran on two things: knowing precisely what counts as a rage click, and knowing where PostHog surfaces one. Both are worth breaking down before getting to the point where doing this every time stops being realistic.
What a rage click actually is
A $rageclick isn't a vague "user seemed frustrated" score. PostHog's autocapture documentation defines it precisely: the event fires "once it sees three clicks that are each within 30 pixels and 1 second of the previous one." Three fast clicks in roughly the same spot, nothing more. It requires autocapture to be running in PostHog's JavaScript web SDK, so a mobile app or a page where autocapture is disabled won't produce one no matter how frustrated the user is. Dead clicks, a click that isn't followed by any change to the page, are a separate, opt-in event, enabled either in project settings or with capture_dead_clicks: true.
Because the detection is purely mechanical, three clicks in a spot, it doesn't know why. PostHog's own session replay docs put this plainly when describing what a raw signal like this needs next: "rage clicks on one button could be a slow request, a confusing label, or a real bug, and telling those apart takes a person." The event tells you where someone got stuck. It doesn't tell you which of your open tickets, if any, is about that exact spot.
Finding the flagged sessions in the first place
Two built-in paths surface rage clicks without you writing a filter from scratch, per PostHog's guide to watching recordings:
- The "Frustration signals" built-in collection, which surfaces sessions with multiple rage clicks or exceptions from the last 7 days. It's a triage entry point, not a match to any specific ticket.
- Asking PostHog AI directly inside the replay list, with a query as literal as "show recordings for users who triggered the rage click event."
Either route hands you a list of sessions. Neither one hands you the ticket that goes with any of them.
The identifier that actually bridges the two systems
Once you have a candidate recording, the match runs on whatever the recording and the ticket both carry:
- Who. If the session is identified, PostHog's person profile carries whatever you passed to
identify(), usually an email or account ID. If it's anonymous, this path dead-ends before it starts, the same identity gap that shows up whenever a signal fires before login. - When. The ticket has a submission timestamp; the recording has a start time. A rage click a few minutes before or after a customer's message about the same page is a strong match, not a certain one.
- Where. PostHog tags every event with
$current_url. A rage click on the same page the customer named in the ticket narrows a list of ten candidates to one fast.
Filter the replay list on the $rageclick event plus the person's identified ID or the page URL, and you're usually looking at one or two sessions, not a list. From there it's a normal read. Open the recording, watch the three clicks, and check whether what you see matches what the customer described. Once you're sure, leave a comment on the recording itself, PostHog's replay viewer supports comments and can turn one into a task directly, so the match survives past whichever browser tab you found it in. If the bug needs its own engineering ticket, PostHog's docs also describe attaching a clip straight into a Jira or Linear item, which is a separate hop from the original support ticket, not a link back to it.
What one confirmed match doesn't tell you
The Dockline example took about ten minutes, mostly because Klara already knew which account and roughly when. That doesn't hold at volume:
- It's a lookup per ticket. Filtering by person and URL is quick once; doing it for every claim-button complaint that week is a job nobody was hired for.
- Anonymous sessions dead-end immediately. No
identify()call before the rage click means no person profile to filter on, so the "who" half of the match never resolves. - A confirmed match isn't written down anywhere both systems can see it later. The link exists in a comment on the recording and nowhere else; the next teammate who opens the ticket first has no way to know the session was already found.
- Nothing here counts how many other tickets are the same underlying bug. Klara found one match. Whether three more shippers hit the same permissions gap that week is a separate search she'd have to remember to run.
After the comment is left
Fixing those four gaps isn't a faster filter, it's not re-running the same lookup every time a ticket about the same page comes in. Modem's PostHog integration reads product analytics, feature flags, experiments, and error tracking, not session replay, so it won't watch for the rage click or make this exact match for you. What it does is the other half of the problem. Once Klara's match confirms which ticket goes with which bug, Modem keeps that topic intact across every other channel the same complaint shows up in, Zendesk, Slack, and email, so the third and fourth shipper who file about the same claims-page failure land on the existing topic instead of opening a fresh investigation, with the feature flag and error-tracking context from PostHog pulled up next to it. I build Modem, so read that fact with that in mind: it doesn't do the per-ticket lookup itself, and pricing is unlimited users on every plan with usage-based volume beyond what's included, not a charge per person filing a claim. A related gap, catching the same failure across support channels before it reaches PostHog at all, is covered in how to tell if multiple customers are hitting the same bug across different Slack channels, and the identifier-matching approach itself is the same one used to connect Sentry errors to the support tickets that reported them.
Before the next rage click comes in
Confirm identify() fires before your highest-traffic authenticated flows, not just at login, so a rage click three screens into a session still resolves to a real account instead of an anonymous one. That single check decides whether the next ticket like Dockline's takes ten minutes to match or dead-ends before Klara even opens the recording.
