How to see the PostHog session recording behind a Zendesk ticket
Pull up the ticket, copy the requester's email, and search for that email on PostHog's Persons page. Open their profile and click the Recordings tab. It lists every session replay that person generated, and you can sort by time to find the one that ends around when the ticket was filed. PostHog does have a native Zendesk source. It syncs tickets, ticket events, users, and more into PostHog's warehouse, so you can query support activity with HogQL. What it doesn't do is put a button on the ticket that opens the matching recording, or resolve the two products' identities into one profile automatically. That link still gets made by hand, using the customer's email, the one detail both systems record.
This works reliably once you've done it a few times, and it breaks down in specific, predictable ways once ticket volume climbs. Both halves are covered below.
Step 1: get the identifying detail off the ticket
You need something PostHog also knows about the person. Email is the reliable one, since it's the requester field on every Zendesk ticket, and per PostHog's identify() docs, email is commonly set as a person property (or even used as the distinct_id itself) when a team calls identify(). If your app instead identifies people by an internal user ID or account ID, use that instead. Whatever value your app passes into identify() is the value that finds them in PostHog.
Also note the ticket's created timestamp. You'll need it in step 3 to pick the right session out of a list.
Step 2: find the person in PostHog
In your PostHog project, open Persons and search by the email (or ID) from step 1. PostHog's persons documentation describes the profile page you land on. It shows person properties and distinct IDs, plus a row of tabs (Events, Recordings, Cohorts, Feature Flags) for that specific person.
There's one identity wrinkle here. If the customer was browsing anonymously before they logged in, their early events sit under an anonymous ID until your app calls identify(). PostHog then retroactively merges the anonymous history into the identified profile, so a session that started before login still shows up under the same person once identification happens later in that session. If your app never calls identify() for this user, though, there's no profile to search for by email at all. The sessions exist, but they're anonymous, and email won't find them.
Step 3: open the Recordings tab and match the timing
Click into Recordings on that person's profile. It's a list of every session replay PostHog has for them, subject to your project's recording retention window. Sort by most recent and look for the session that ends shortly before the ticket's created timestamp from step 1, since that's usually the one where whatever went wrong actually happened. Recordings play back click-by-click with console logs and network requests alongside, per PostHog's session replay overview, so you're not just watching a cursor move, you can see the failed request that caused it.
If more than one session ends near the ticket time, open the closest one first. A support ticket filed minutes after a session ends is the strongest correlation you'll get without an event that ties the two together explicitly.
A ticket that took two minutes instead of a re-explanation
Draycott Robotics sells warehouse routing software to logistics teams, and Kade Lund is the one who ends up triaging tickets when something breaks mid-shift. A ticket came in from an ops lead at one of their accounts:
Reported by ops lead, Case #8841: The route re-optimize button just spins. Tried twice. We're mid-shift, need this working.
The report doesn't say what "spins" means, what the customer had already tried, or whether they'd hit a specific error. Kade copied the requester's email off the ticket, searched it in PostHog's Persons page, and opened the Recordings tab. The most recent session had ended eight minutes before the ticket came in.
Watching it took under two minutes. The customer clicked re-optimize, a network request to the routing endpoint returned a 504, and they clicked it two more times before giving up and filing the ticket. No timeout retry, no error message shown in the UI. The button just looked broken. Kade pasted the recording link into the ticket as an internal note and tagged the on-call engineer with the actual failure instead of "button does nothing." The fix (a retry with backoff on that endpoint) shipped the same day, and nobody had to ask the ops lead a single follow-up question during a shift they'd already said was busy.
Three ways the email trick breaks down
The email-search path works fine at the volume Draycott was running it, a handful of tickets a day, mostly triaged by one or two people who remember to check. It stops being fine on three specific axes:
- It depends on someone remembering to do it. There's no prompt on the ticket that says "check PostHog." A tired agent on ticket forty of the day just replies and moves on, and the recording, if it exists, never gets watched.
- The identity match can fail silently. An anonymous session, a different email used to sign up versus the one used to file the ticket, or a person who simply hasn't triggered
identify()recently all produce an empty Recordings tab, and there's no way to tell "empty because nothing happened" from "empty because the match missed." - It doesn't survive rising ticket volume. Copy-search-open-sort-watch-paste is maybe three minutes per ticket done well. At ten tickets a day that's half an hour of manual identity-matching before any actual support work happens.
Past that point, teams generally aren't looking for a smarter search box. They're looking for the identity match to already exist by the time the agent opens the ticket. That's the point where we'd bring up Modem. It connects to Zendesk and to PostHog separately, and it resolves both to the same person and company record automatically, the way it does for every source it watches (Zendesk integration, PostHog integration). An agent working a ticket in Modem is looking at a person who's already tied to their PostHog activity. The manual email-search-and-match in steps 1 through 3 above is the part it removes, not the recording itself, which you still watch in PostHog. We build Modem, so read that recommendation with our bias in mind. Below a few tickets a day, the walkthrough above is genuinely enough, and adding a tool to save less than half an hour of manual matching a day isn't worth it.
A cheap habit that covers most of this
If you're not at that volume yet, the cheap fix is a habit, not a tool. Add one line to your ticket-triage checklist: "if the report describes broken behavior, check the requester's PostHog Recordings tab before replying." That single line turns "button does nothing" into an actual diagnosis most of the time, for the cost of a two-minute search. For the analytics side of this same pairing, how to pair PostHog data with customer feedback covers the broader set of questions this connection answers, and can PostHog link a bug report survey to the session recording automatically covers the same linking problem from PostHog's own in-app survey tool instead of a Zendesk ticket.
