How to see Zendesk tickets and Sentry errors for the same bug together
There's no setting that puts a Sentry error group and its Zendesk tickets on the same screen. You get there by picking one piece of data that exists in both systems, usually a customer's email or an account ID, searching each tool with it separately, and holding the two results next to each other yourself, in two tabs or two windows. Neither product knows the other exists, so nothing does this join for you automatically.
That's not a missing feature so much as a category mismatch. Sentry's integrations directory groups everything it connects to under Source Code, Deployment, Project Management, Notifications, Data, Session Replay, and SSO. There's no help-desk category, and Zendesk isn't listed under any of the others either. Zendesk, for its part, has no field for a stack trace. The two tools were built to watch different things, an error rate and a queue of conversations, and seeing them together for one bug is work you have to assemble by hand.
Find the identifier that exists on both sides
The join only works if both tools are recording the same value. On the Sentry side, that means someone called Sentry.setUser({ id, email, username }) in your app, which Sentry's own docs are clear isn't automatic. Skip that call on a given code path and every event from it carries no identity at all, no matter how the issue is searched afterward. On the Zendesk side, the requester's email is already there on every ticket, and ticket tags are fully searchable, so tags:scheduling-bug or a saved view built on that tag will pull every ticket about one recurring problem.
Once both sides carry the same email, an account ID, or a shared tag, you can search on it twice, once in Sentry's issue search and once in Zendesk's ticket search or a view built for it.
Build the view before you need it, not during an incident
The search itself takes thirty seconds once you know the identifier. What actually eats time is doing that search cold, mid-incident, for a bug nobody wrote anything down about the last three times it came up. The fix isn't a smarter search. It's a small standing artifact that already has the pairing in it.
A simple version: one row per recurring bug, in a doc or a spreadsheet, with four columns. Sentry issue link. Zendesk tag or saved view. A rough weekly count from each side. A one-line decision, "watching" or "fixing this sprint." Update it whenever a tagged ticket comes in or the Sentry issue's event count moves, and the next person who opens it isn't starting the join from zero, they're reading a decision someone already made with both numbers in front of them.
This is a different problem from linking one Sentry issue to the one ticket that reported it, which is worth doing too and is covered separately in how to connect Sentry errors to the support tickets that reported them. That guide is about writing down a single match. This is about keeping a running view of a bug's two signals so a prioritization call doesn't require re-deriving them from scratch.
A recurring-schedule bug at Loomwell Data
At Loomwell Data, crew leads set recurring shifts for commercial cleaning teams, and a nightly job regenerates the coming week from each account's template. Ffion Casey runs support there. Two months ago she started noticing the same two accounts, Corley Cleaning Co. and Duskvale Facilities, filing a ticket almost every Monday, always some version of half their crews not getting next week's schedule. Each ticket got tagged scheduling-bug and closed with a manual regeneration, because the workaround was fast and nobody had connected it to anything on the engineering side.
After the third Monday in a row, she asked in the shared #eng-support channel whether this was the same bug every time or three different ones.
That question landed on Kwabena Osafo, a backend engineer who'd been watching TypeError: Cannot read properties of null (reading 'shiftId') fire in Sentry for two months, four or five times a night against the nightly regeneration job. It never spiked, so it sat unresolved and low priority while he worked through a larger release. He pulled up the Sentry issue and filtered tags:scheduling-bug in Zendesk for the same date range: both accounts' emails matched the user.email values on the crash. Four or five failures a night in Sentry, quiet enough to stay buried under real work; two frustrated Monday tickets from named accounts on the other side, each one costing a manual fix. The event count said not urgent. The ticket pattern said same two paying accounts, every single week, and support doing the fix by hand each time. He filed it that afternoon and shipped a null check two days later.
The costs that pile up on a doc nobody's paid to update
The row-per-bug doc above is a fine habit for a handful of recurring issues:
- It only grows. Every bug someone bothers to write down is one more row to keep current, and the doc goes stale the first week nobody updates it after a fix ships.
- The counts are snapshots, not trends. A weekly glance tells you "four events, two tickets," not whether either number is climbing, and that trend is usually the thing that actually decides urgency.
- Nothing forces the pairing to happen at all. The whole system depends on someone remembering that this week's ticket is the same bug as last week's, which is exactly the kind of pattern-matching that gets missed when the person who noticed it last time is out.
What an integration changes about the search
Modem is one way to close that gap. Modem ingests Zendesk tickets directly, so tagged conversations from the same accounts land in one topic automatically instead of waiting for someone to notice the pattern. Modem doesn't pull Sentry's error data into that topic the same way, but connect Sentry and the agent can search issues, read stack traces, and pull the matching error up next to the ticket topic on request, so answering "is this the same bug that's been costing us manual regenerations for a month" doesn't mean opening two tools and matching emails by hand. The underlying idea, keeping a bug's error data and its customer conversations reachable from one place instead of scattered across systems that don't know about each other, is the same one behind a customer context graph. I'm on the Modem team, so factor that bias in. If you're only tracking a few recurring bugs a month, the row-per-bug doc above is a reasonable place to stay.
The next Monday ticket is your cue
Pick the recurring bug you've manually re-explained the most times this quarter, find its Sentry issue and its Zendesk tag, and write one row: issue link, tag, this week's counts on each side, and a decision. The next time it comes up, that row is the answer, not another cold search through both tools.
