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 state of the art. There's no vendor selling this connector. Teams that do it well built the glue in-house.
The first search misses when the failing code has no user attached
Support hands you a ticket: an account says one action fails every time this morning, and the ticket has the exact click path. You open the relevant project in Sentry and search user.email: with the account's mail domain. Nothing comes back.
That is not proof the error isn't there. The work that actually failed runs as a background job under a service account, not in the browser session where Sentry.setUser() fires, so those events were never going to carry an email at all. Switch identifiers. If that job sets a tag for the account it is running on, such as account_id, filter on the tag instead and narrow to the time window the ticket gives you. One issue lines up: the exception thrown by that job, starting when the customer says the trouble started, every event carrying the account's tag.
Now write the match down in both directions, because neither tool will do it for you. Comment the ticket number on the Sentry issue's Activity tab, and link the fix in your tracker from the same issue. Then post an internal note on the ticket with the Sentry issue link, so the next person who reads it sees a confirmed cause instead of an open question.
None of that is reusable. The next ticket starts with the same failed email search.
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
Once the matching takes most of someone's day, 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 account 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, 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.