APIs for Sentry Insights

[Dhrumil-Sentry]

Developers triage and fix issues they see on Sentry often leveraging our integrations with other tools like Slack, Jira, or Github. Sentry also offers a rich set of insights with key metrics at the project, team, and release levels. We’ve heard feedback about how difficult it is to access these insights and surface them in external tools programmatically due to a lack of published Sentry APIs.

We’re looking to fix this and would like to hear from you about what matters to your workflows.

What insights does Sentry show today?

Sentry shows several aggregated stats in our app and some of these are listed here.

• View critical metrics for a project on the project details page
  

• View information about the new, regressed, and ongoing issues for a release on the Release Details page
  

• View information about issues triaged by your team on your organization's stats page
  

Sentry also allows developers to create custom dashboards to track the specific stats they care about. These stats give developers a comprehensive view of how their team is triaging issues with Sentry and the overall health of their application.

What APIs would you like Sentry to build or publish?

We’re actively looking into building APIs that allow you to access the insights we show within Sentry and we’d like to hear from you on what matters to your workflows. Specifically, we’d like to learn about

• What insights in Sentry matter the most to you?
• What other data in Sentry would you like to access via APIs?
• What other APIs would you like to see from Sentry?

[cathteng]

The projects stats table is very useful for users. We've heard of users scraping the webpage to collect the data and have had several asks on how the data is actually generated, so it would be awesome to have an API for that!

[brianmichel]

One thing that we've tried to build a few times with the Sentry APIs is trying to effectively export data into something like BigQuery or any other data warehouse since there are usually a lot of ad-hoc queries we want to run on say a given release, or how a release compares to another release.

With the existing APIs this is extremely challenging, often times you can get the raw event, but trying to back fill the information that gets created for the issue into those events ends up making this kind of a challenge just not worth it. I would push to consider how users of Sentry could export their data in a way that would give them the ability to run rich queries in external tools, this could provide for an extremely large set of use cases.

Another issue we've run into is that the way Sentry sorts release numbers in a dashboard setup. A common dashboard we want to build is total number of crashes per release sorted by most recent release (so we can see if volume is going up or down across releases) and for whatever reason the built in tools do not understand all version number combinations, it would be great to fix this to allow people to get more value out of the builtin tools as well.

Finally, a major improvement would be the ability to use something SQL-like in the query fields that are common in the API. Many times trying to figure out how to group the data that comes out of Sentry is challenging, and typically ends up with us flushing data into some kind of intermediary file and then re-querying it. This is pretty frustrating, embracing something a bit more common here could make people's lives much easier.

I'm happy to provide links to our Sentry dashboards where we've struggled to craft exactly what we want if that would help!

[Dhrumil-Sentry]

@brianmichel Thanks a lot for this detailed feedback !! 🙌

We'd love to understand some of the ad-hoc queries you'd like to run on the Issue/Error event data. We're actively considering this use case today. Would exporting issue and error event data suffice for your use cases or do you only care about issues data with some aggregated information?

Many times trying to figure out how to group the data that comes out of Sentry is challenging

Could you please share an example of the type of information you are searching for here? 🙏

[brianmichel]

Absolutely! We build a browser for desktops, so often things like OS versions make a different in how our code works since the OS creator updates SDKs as they go along. So trying to get an idea of how crashy things are per release per OS is hard to do (maybe impossible?) with the existing Sentry UI for creating a dashboard. Here's an example of me trying to quickly craft a dashboard like that:

I've had to pick the "errors and transactions" dataset here because the os field isn't available in "Issues" or in the "Releases" dataset (which is actually where I would have naturally tried to start since the question i'm asking is about a release). As you can see in the attached screenshot, this doesn't really give me what I want for a couple of reasons:

1. Sorting by release doesn't seem to understand semantic versions or something like that (as I've already mentioned) I want to see my most recent builds, and this is not them.
2. Ideally I want to group these OS into macOS 12, macOS 13, etc. but there's no way to do that. I've tried messing with count_if but for whatever reason there's no "contains" option in the drop down in trying to structure this query (all of the options here seem to assume a numeric value)

Would exporting issue and error event data suffice for your use cases or do you only care about issues data with some aggregated information?

This is a great question and initially I thought events would suffice, how does issue information get aggregated and enriched from a set of events? While I've only been talking about crash information, we also use Sentry for function tracing and each transaction event isn't as meaningful there, ideally we could easily export a complete trace, are you considering automated transaction data export as well?

[brianmichel]

Another good example that's surprisingly hard to figure out how to do (this time through the API) is when I want to figure out which user's are crashing the most out of a given release. This let's us identify folks to reach out to and do a live debug session on what's going on.

To build this, I'd start by looking at https://docs.sentry.io/api/events/ to see how I can query all of this data, however there's no way to pass a query to the events endpoint, so then I would look at issues which doesn't really do it either, and finally I looked at the discover data set, which would work, but I have to continually page through all of the data and compute this myself. A question like this seems like it should be answerable in a much more straightforward manner.

[Dhrumil-Sentry]

Thanks a lot for these detailed examples @brianmichel 🙏 , Your dashboard example to track crashes per release is a logical ask which we'll discuss internally since we've heard similar feedback from other users too

This is a great question and initially I thought events would suffice, how does issue information get aggregated and enriched from a set of events? While I've only been talking about crash information, we also use Sentry for function tracing and each transaction event isn't as meaningful there, ideally we could easily export a complete trace, are you considering automated transaction data export as well?

AFAIK when an event is ingested by Sentry it has a unique fingerprint and gets grouped into an issue that has the same fingerprint. The event also goes through a post-ingestion job that evaluates Suspect Commits, Issue Assignment, etc based on the event's stacktrace. But a lot of the data you see on the Sentry Issue List or Issue Details such as the event counts is being queried real-time from the event storage directly.

We don't have any plans to support trace export yet

Another good example that's surprisingly hard to figure out how to do (this time through the API) is when I want to figure out which user's are crashing the most out of a given release. This let's us identify folks to reach out to and do a live debug session on what's going on.

You'd need to use the Discover API and pass the query you'd use in the Discover dataset and retrieve the events for a particular release. You'd then need to query the individual events via the Retrieve an Event API and then write custom logic to parse the event payload to find the answer you are looking for.

This is indeed quite convoluted today 😬

[efeozsoy]

Hello recently I was trying to link Jira tickets to Sentry issue but I found out that it can only be done via frontend. We can create Jira tickets but we can not link existing ones through the API. It might be handy, please consider it. Thanks in advance.

[Dhrumil-Sentry]

@brianthi @rachrwang - This is an action users can take on the Issues page UX today- Worth adding this to the backlog to enable users to programmatically link existing Jira tickets

[efeozsoy]

hello @Dhrumil-Sentry Did you have a time to consider to applying this feature? we are still doing this manually.

[ento]

My current needs are similar to this post from the old forum: https://forum.sentry.io/t/summary-of-projects-issue-events-count/4069

In particular, I'm interested in being able to easily query metrics that my team can use to track whether we're consistently triaging issues:

• total number of unreviewed issues in a project
• total number of events of unreviewed issues in a project
• total number of unique user.id values of events of unreviewed issues in a project (This is more of a nice to have)

It'll be great if metrics like these can be pushed to Datadog as well.