How to connect Sentry errors to the support tickets that reported them
There is no button for this. Sentry has no concept of a support ticket, and Zendesk and Intercom have no concept of a stack trace, so matching a Sentry issue to the ticket a customer filed about it means finding one piece of data that already exists in both systems and searching across from one to the other by hand. That's usually the customer's email, the time the error fired, or the URL and action they described.
Once you find the pair, the match has to be written down somewhere, because neither tool remembers it for you. Paste the Sentry issue's link into an internal note on the ticket, and drop the ticket number into a comment on the Sentry issue's Activity tab, where Sentry confirms "any comments users leave on an issue will also appear." That two-way pointer is the whole trick. Everything below is about finding the shared identifier fast enough that doing this by hand doesn't eat an engineer's whole morning.
Why there's nothing to configure
Check Sentry's own integrations directory and the categories are Source Code, Deployment, Project Management, Notifications, Data, Session Replay, and SSO. Project Management covers Linear, Jira, GitHub, and a handful of others, which is how an issue gets linked to a tracker automatically. There's no help desk category. Zendesk, Intercom, and Freshdesk are not in there either, in any direction. Sentry isn't hiding a setting you missed. The connector doesn't exist.
What Sentry does give you is a search index. Its searchable issue properties include user.id, user.email, and user.username, plus any custom tag you've set with setTag(). None of that populates on its own. Sentry's user context docs are explicit that you call Sentry.setUser({ id, email, username }) yourself, and if it never fires on a given code path, the events from that path carry no identity at all no matter how the search is phrased.
The manual runbook, borrowed from a team that does it daily
GitLab's public support handbook documents the workflow its own support team runs against Sentry, and it maps directly onto the ticket-matching problem:
- Pull an identifier off the ticket. A username, an email, or the URL the customer was on when things broke.
- Search Sentry directly, with
user.username:,user.id:, or a URL filter on the relevant project. - Fall back to logs when the direct search misses, which the handbook says "won't always" work. GitLab's fallback is filtering their Kibana logs by username, controller, and status code to pull a correlation ID, then searching Sentry for that ID instead.
- GitLab built a purpose-made internal Zendesk app just to convert a username into the ID Sentry needs. Even a team that runs this search daily didn't get it for free; they wrote the lookup tool themselves.
That last point is the honest state of the art. There's no vendor selling this connector. Teams that do it well built the glue in-house.
The morning Briarcliff Dental couldn't reschedule anyone
Palfrey builds scheduling software for dental and medical clinics: patients book online, front-desk staff reschedule from a shared tablet, and a background job sends the confirmation once a slot changes. Priya Deshmukh runs support. Desmond Yarrow is the backend engineer on call.
Priya (Slack, 9:14am): Briarcliff Dental says nobody can reschedule a cancelled slot this morning, front desk gets a blank error page every time they try. Ticket #4192 has the exact click path if you need it.
Desmond opens Sentry and searches user.email:*@briarcliffdental.com in the scheduling service. Nothing. The reschedule confirmation runs as a background job under a service account, not the front-desk browser session where setUser() actually fires, so the office manager's email was never going to show up there.
Desmond: Her email's not on anything. Checking by clinic instead, we tag the reschedule job with
clinic_idsince it doesn't have a real user attached.
He filters by the clinic_id tag matching Briarcliff's account and the time window from the ticket, and one issue lines up: a null reference in the reschedule job, 31 events since 8am, all carrying that clinic's tag. He comments Priya's ticket number on the Sentry issue, files the fix as a Linear ticket, and replies to Priya.
Desmond: Found it,
clinic_idmatches Briarcliff, 31 events since 8am. Linked #4192 on the issue and filed the fix as PAL-889. Reply to them whenever, this one's confirmed.
Priya posts an internal note on ticket #4192 with the Sentry issue link and a two-line reply to the clinic. The match took about fifteen minutes once Desmond stopped searching by user and started searching by tag. Nothing about that fifteen minutes gets easier on the next unrelated ticket; the next engineer starts from zero again.
The manual match falls apart at volume
The runbook above is fine for one ticket a week:
- The identifier isn't always obvious. Background jobs, webhooks, and service accounts routinely have no
setUser()call on that path, so the first query misses and someone has to know to try a tag or a time window instead. - The match lives in someone's memory or a Slack thread, not in a place either system's next reader will find it, unless the comment-and-note step above happens every single time.
- It scales linearly with volume. One match a week is an interruption. Ten a day is most of someone's job, and it's a job nobody was hired to do.
Where this becomes Modem's job
Past that point, the fix isn't a better runbook, it's not needing to run one by hand every time. Modem's Sentry integration lets the agent search Sentry issues, read stack traces and sample events, and pull that up next to the Zendesk or Intercom conversations your customers filed about the same problem, no separate search by email or clinic tag first. Modem doesn't ingest Sentry's errors and issues into its graph the way it ingests tickets; what it ingests is the user feedback submitted through Sentry itself, and its context layer links the stack trace to the topic customers are already raising, original quotes attached. Ask about the topic and the agent already has the error behind it pulled up. That's a looser join than the exact ticket-to-issue match the runbook above does by hand, but it's the one that scales.
Modem is what I work on, so read that paragraph against the cost of building GitLab's internal tooling yourself. Once a match exists, the next question is usually which other customers hit the same error, a related but separate join. A wider comparison of tools working this same gap is in the best tools to connect Sentry errors to customer feedback.
One tag now saves the next search
Add a custom tag, like account_id or clinic_id, to any code path that runs without a logged-in user attached, background jobs and webhooks especially. It won't replace the search-and-comment habit above, but it turns the first query from a guess into a filter that actually returns something.
