Tracking errors and slowdowns across JS applications using Sentry

♪♪ All right. I'll go ahead and get started. Hello, everybody. My name is Simon. I'm a solutions engineer at Sentry. I'll just start sharing my screen here. Let's make sure... Share. My desktop. All right. So everybody should see my desktop. Got a slide deck prepared for us and we can go through kind of this topic that we're all joined here for is tracking errors and slowdowns across JS applications using Sentry.

So by way of introduction, my name is Simon Zhang. I'm a solutions engineer at Sentry. And I've got a few slides for us to go through kind of end-to-end process of getting us situated with Sentry, the SDK on our application and also how we can go into Sentry to, you know, track the errors, track the slowdowns, notify necessary people, work through the workflow that we supply through Sentry, optimize the user and developer experience all with our platform here. Just to continue on through this agenda to keep us organized today, I'll start off with describing application monitoring, what Sentry is designed for and how and why it's important. Then go into the weeds a bit with the Sentry integration steps. So that includes getting the SDK on our apps. I've got a couple apps for us to do this with, so a React front-end and a Node Express back-end. So, both JavaScript apps and we'll get a project created in Sentry and also integrate these applications with those Sentry projects. So, Sentry project and application, those are like mapped one-to-one. We'll go into the details there but, number three, errors and performance. So, we'll talk about error monitoring and performance monitoring. Step four, or chapter four for us, will be going through alerts. So, notifying the right people off of the errors and performance, you know, data that we capture. We organize the data by releases. So, we'll talk about that as well and go over Discover and Dashboard, how we organize and slice and dice data that we care about in our team and our organization or just to look at our data for fun. Whatever we wanna do with the data we capture, we can do it through Discover and Dashboards.

Now, with the meeting that we have together, this is on Zoom, right? And we have, it looks like our Q&A feature might be a little wonky today. So, we'll try to sort that out.

Feel free to unmute when, you know, I pause for questions and I'll also pause midway and by the end of the session, I'll do a quick break for questions as well or feel free to just type it in chat and I can get to that when, throughout the meeting as well.

So, with that, let's start with the first bit here. So, what is application monitoring and why? So, let's start off first with reviewing a problematic application. This will kind of give a more hands-on example of what we're looking for. So, I've got this application that crashes periodically. So, I'm just going to refresh it a bit and it crashed. Okay, what the heck happened? So, this is one thing we need to worry about for this problematic application. Sometimes it crashes, sometimes it doesn't on a refresh, on load. Another problem with this application is when I go into looking at these products, it's an eCommerce site, I'm looking and trying to buy stuff as an end-user, right? I've got my end-user hat on, took a long time for me to see the products that I want to buy, and lastly, when I try to check out and buy the products that I've added to my cart, we encounter an error. So, we've got three problems with this application and as an end-user, I'm frustrated, confused, I don't know what's going on. Maybe I'll click this to reach out to the developers or whoever's in charge to, you know, notify them of these problems, but it's just not a cohesive way to do it. And as an end-user, I might just, you know, try again later or just give up on buying these things in my cart. So that's without Sentry and something that we need to figure out. So that's the problem situation, what we're trying to fix together.

Now without Sentry, maybe we'll get notified of this problem that we're experiencing, try to reproduce it as we, you know, enter the problem through that page load. Oh, I can't reproduce it, what's going on? Or I eventually do reproduce it and I look at my console to investigate what's the problem, maybe check out the network tab as we reproduce the problem as well. There are opportunities here to figure out that problem we experienced by the end user, but it's not as streamlined and efficient as we'd like, not as trackable either. So that is why we care about application monitoring. We want, as the developers, we want to know the problems in our code and the user experience with the code we write. So that's why we've got Sentry, right? So Sentry is focused on code observability. We monitor the health of an application from the front end to the back end. And with the Sentry SDK on your application, the concept is to set up alerts. And these are like targeted alerts that aren't noisy and not spamming our team members. So we'll set up very specific and granular alerts with our alert platform, those necessary or the important team members and developers would be notified and they can work through the issue. All the details that are captured by Sentry are all available for them to understand the context, what the user experience as well, any clues on which problems might be related and also what parts of the code are important, things like that, contextual information through a timeline of activity and tags will talk about as well. At the end of the day, we'll figure out what's going on, make the necessary commits and then fix the problem, right? That's the way we would incorporate Sentry in our application.

Now to follow along, what we have is a demo app. So that's what this URL is for, but if you want it to, and that's what we'll be reviewing together. So I've got one running locally and I've also got one that's hosted. So we'll go through both and tinker a bit with the one that I've got running locally.

If you want it to follow along with your own application, we'll go through the steps to integrate Sentry, the SDK on React and Express. You can create your own app with create React app or Express generator, and that'll be like a blank slate and you can kind of add a Sentry to that, generate errors and you'll see it as well. But I'll be using my own locally run demo app that we've got cloned from this repo.

But after figuring out which app we wanna use for this, you can sign up through Sentry.io signup, create projects from there, but we'll do this together. We'll also have this meeting recorded. So feel free to just, you know, sit back and watch as well. We have docs available for how to get started with React and Express specifically and other frameworks and languages also. So that's through our docs Sentry.io page, Sentry documentation. We've got all our supported languages and frameworks right off of, some on the front page here, but for all of them, you can click into this button to go into the details of whatever application you want to run with Sentry.

In any case, let's go ahead and get started. Okay, so I'm here. With configuration, we have details through these doc pages. So we jumped into, from our documentation page, we can go into our React documentation through this button here. And what this does is, or the details described in this documentation page is how to install, right? How to get our libraries in with an NPM install or a Yarn add. And then we'll configure Sentry with Sentry.init. So with these details, we would have Sentry incorporated in our application, as described here. Once this is done, all unhandled exceptions are automatically captured by Sentry. That's on the React side. We also have integrations with React router and Redux, which I'll show in my application here.

So I've got my app right here, and the details on the Sentry.init, just to replicate and match what we see here. I'll go through in more detail. As actually, let's start off with creating our project. So once you sign up, you'd have your own organization, and you can create a project as I'm doing here. So I'm gonna create a project. Let's start off with React, as we've been talking about, and with React, or with any project rather, you can set your default alert settings. So this is a very basic alert, and we'll go into more details about more complex alerts, in, I think, number four, chapter four. We can just start off with alerting me on every new issue. So we'll start with that, set our name. So let's say DevOps React. We have our users organized by teams.

So I have my Simone Limon team. Create the project right away. And once you create the project, then details on how to get started are basically mirrored in the following page. So everything that you see here is also available in the docs directly for more detail. But let's just go off of this.

So we have our Century React and Century Tracing packages that we need. So just going back to my app, that's in my package JSON. So Century React, Century Tracing is added there. So I'd install it with NPM install for me.

Now going back to the Century Init portion, so we'll import them as well, but going to the Century Init portion. So that's in my index.js. We have that already. And the DSN key, so that's the data source name, is also created or is also replaced in this step. So this DSN tells your application where to send error and transaction events to, and that's this specific project in Sentry. So I'm gonna copy this, paste it in my code, and we can add integrations.

So this is what we can automatically instrument off of Sentry. Details on that are also available in the docs through this page, but also more specifically in the React guide. So details on the automatic instrumentation of the browser tracing integration is detailed here. So what this will do for us is with every page load and navigation, we'll have a transaction generated. We'll go through what that means, but just keep in mind that's a transaction every time there's a page load or navigation.

Okay. So now bouncing back from these steps to my app here, we have our integrations with browser tracing. So I've set that up, added some tracing origins to allow certain parts to be traced. And also we talked a little bit about the React router integration and also Redux. So those details are available in the instrumentation side with Redux. Redux integration details here and React router details here. So I've added those and we'll see how that's represented in our app. Once we have that and I've replaced the data source name with the one provided from creating the project. So now we can go to our issues. As now, as this application is running errors and transactions would be, or errors would be visible in our issues page.

Okay, so we've created one, our DevOps React project just now. We're just going to do the same thing, but now it's for our Express project. So I'll create my project, Express. Let's do the same alerts to alert me on every new issue. DevOps Express, same team, let's keep it simple.

Create the project, now same deal. I have my Express app here, added the sentry node, sentry tracing in my package json. So I have the latest versions as well. Setup is the same thing. I'm copying the data source name in my application and set up the integrations accordingly as well. Details on what configurations are available are all listed out from this page or also in the corresponding docs page. Express specifically, you can find within the NodeJS.

All right, so with both of these, with the updated data source name now, I'm just gonna go ahead and please ignore all the errors that come up when I do an npm install, but I'll do the same for both. My local apps here. And start the projects. Okay, so with that, I'm running them both locally, let's continue on through here. We've talked about the configuration, what's available through the guides, the details on the integrations there, what's automatically captured, those errors and exceptions. And now, we can talk about getting situated with the Sentry integrations, and that's with uploading our source maps, particularly for our front-end app.

So, in our React project, I've got source maps set up, and I've also set the environments and release details through our run script. Source maps, specifically, I think we're all a little familiar with, where our production-level code is minified for optimal performance, right? But that makes it a little complicated for us to decipher what the stack trace is because it's minified, it's not human-readable. So, the solution to that is uploading your source maps to Sentry. We've got a docs page available for details there. How we can provide them to Sentry, we can upload them directly, and that's what we recommend. I've got it set up through a Sentry CLI tool. The way it works for me, and you can replicate it the same way, is with the Sentry CLI tool, we can set our release details, our project details with it as well, tell Sentry what release to associate our source maps with, and from there, our source maps would be uploaded as during our build process and when we serve it locally.

All right. Okay, and these documentation pages will consolidate and send after this session. So as questions come in as well, we'll see what's relevant for you all and share the relevant details or corresponding documentation pages for you to look into in more depth. Okay, so those are source map details and we've got that set up in my local app as well. Now we're integrated.

So with the problematic application we experienced earlier, we'll have our session details sent to Sentry that'll help us figure out whether users had a clean exit or not. You know, when they're using your application from start to finish, did they experience any errors? That'll help us understand the crash-free session rate detailed according to releases.

We also have errors sent up to Sentry and transactions as users are interacting with our app. Great. So now with Sentry, let's do the same deal. So I'm running off of Localhost now. So, actually before I go too deep into it, we did create alerts, right? And we wanna be notified when errors are happening. So with our DevOps projects, let me actually, we have no errors happening yet. We haven't triggered them, but we did get those default alerts set up. Now the default alerts, they're not gonna send it to anywhere in particular yet until we really tell them where to send it. It can send to issue owners, but we don't have a way to set the issue owners until we get into the rules, which we will. But just to get us started, I'm gonna tell for this alert role, when a new issue is created, I wanna be notified through Slack. I've got the Slack integration set up already. But once you get that situated, you basically define the workspace and where those notifications would go into. So for me, I want them to be sent to this Slack channel.

Okay. So with that, let's add SimonSentry catch-all workspace. Let's add some context like customer type. Let's also show some other information. So when we're notified of the problems, we'll also get some context on the notification. So customer types helpful, let's do environment is nice, and this is comma separated. And also let's get the user information. With that, we can set an action interval so we don't get spammed. Every five minutes, we can get notified, that's fine. Not too bad. And that's good enough. So that's for our express alert, and that'll tell us when a new issue comes up. We also have the same alert for our react project. So let's update that. Same information.

So we can add multiple actions by the way, but I'm just kind of deleting the previous and adding a new one here. Let's do the same thing. Sentry demos, my catch all workspace. And of course you can add other workspaces just to keep organized, but for the sake of our demonstration, we'll just use the same one. Customer type, environment and user. Five minutes, save.

Okay. Now going back to our application, every now and then it crashes. So let's refresh it a few times and then it crashed. Okay. So now we have details there. We're just gonna refresh it one more time. The other error we experienced, right? Was the slowdowns loading products. So let me go into that. We wanna capture this information. And now that we've got Sentry integrated, as this stuff is happening, the data is relayed or sent over to Sentry. Just to replicate the same error we experienced earlier, added a couple items to our cart, checked out, received the error. Now on our Sentry, Simon Sentry Catch All Slack channel, I'm starting to get notified of the errors that we just produced with our end user hat in my local app here. So we got three errors. Okay, great. Now with these details, we have visibility. With the integration with Sentry, we have visibility on those crashes, slowdowns, and errors.

Now, let's jump into the errors. We'll just recap once we kind of go through the details here. We can go into the errors through the notifications directly. Remember we set up the notifications to give us the tags with customer type, environment and users. So that helps us as developers figure out, okay, what's relevant here? Should I jump into it? Let's say, yeah, let's jump into it. So let's jump into this one, our DevOps express project. And we also have another error, right? That came in through the Slack channel. This is our DevOps React project we created together.

Now here we have the details on the who, what, when and where of the error we've generated together. Since it's a new project, we're seeing that it happened one time to one user. Okay, we have details on the distribution over time. So last day, last 30 days across releases as we talked about as well. And also we have our tag information. So this is great for when we have more than one error. It's hard to aggregate just one.

So the corresponding error in our case, let's pretend we're jumping, let's travel through time for a minute because I've already got this situated with also a more mature application. But let's look at the corresponding one error, but from an application that has been going on for a while. So I've got this one, same application that where we generated it together actually with our problematic app. And here we have the same details just with more data for me to showcase that, we've grouped these 172 times where this error had happened and it affected 72 users. Its distribution more interestingly over the past day and 30 days across releases. And also now on our tags, we have more interesting information. So this is an aggregate of the 172 times where this error had happened.

Now, going back to the one that we created together, DevOps React, we had talked about source maps, right? So we've uploaded our source maps. Now, instead of seeing that minified stack trace where it's not readable, we don't know what's going on, we have an un-minified stack trace for us to look at exactly where our error happened within our code. And we also have a timeline of activities that led up to this error. So we have understanding of some console information that happened, a fetch call to our backend it looks like, and also, we reached this 500 error. We also have, at the top, a connector showing this event with a child event. So this is where that distributed trace comes from, which we'll get into more details in a minute. But I also wanted to talk about details on the error that happened, not just on our front-end application, sorry, right here, not just on our front-end application with the DevOps React app, but also in our backend. So our DevOps Express app, we've got that triggered as well locally. And details on that, the who, what, when, and where are all available here as well. Okay. With that, that kind of checks off the box for our error side.

Let me jump ahead to now talk about performance. So performance in Sentry is detailed through this diagram.

With that, that kind of checks off the box for our error side. Let me jump ahead to now talk about performance.

So performance in Sentry is detailed through this diagram. We can start off here. We also have a more fun diagram. Maybe we'll do this one.

So this diagram shows how we represent transactions in Sentry or performance details in Sentry. So we have a trace and a trace is a request to an application. When we have a request to an application, we start a trace if there's none already, and we have this yellow application, you can think of it this way, yellow application, blue application, purple application. Our yellow application is doing activity and during that activity, it also makes a request to our blue application, which during that is making a request to our purple application. And as this is happening, we're passing over a unique trace identifier. So as applications are receiving requests, Sentry has added that trace identifier as a custom header. So it knows how to incorporate the request and the transaction and the details behind the scenes and consolidate them together in Sentry. So that's how performance activity works through a distributed trace. So we're tracing activity throughout several applications. Once the original request is completed, then that ends the trace, right? So that's just an overview on what transactions are.

Last thing, spans. Spans are individual operations that happen during a transaction. We can supplement the Details of the spans as well with more data. We'll also talk about Web Vitals. So that's how we can measure our web app and how end users are experiencing it. User Misery Score will guide us in terms of where to look for problematic transactions. And we have Tags and Breadcrumbs, same thing as what we experienced earlier on the issue side, but now from a performance angle.

So with that in mind, what we have in the application we developed or we did together, just going back to our front-end error or front-end project rather, we can go into the performance page. And here we have performance page. Here we have details on our Web Vitals. Since it's a new application, not very useful. We haven't fed in enough data to really make use of it. So that's important thing to note with Sentry is like you kind of want to feed in enough data for us to make sense of what's going on. I'll just review this alongside our existing application here.

So here we have the same application, but this time we have data fed with some web vitals shown right away. So the largest contentful paint details like how long it took for the largest thing to load. FCP is first thing to load, first contemptful thing. How our transactions are behaving against those web vitals. So our products requests for example is very problematic. We also have a high user misery score on that. So Sentry is guiding us to take a look at our products transactions.

So here we have details of just the products transactions, it's web vitals against, how it's performing against our web vitals in the past 24 hours, which is adjustable. If we wanted to take a deeper look at web vitals, we can also do that in our web vitals page. This is if we really care about how our application is performing against these kind of issues. Industry standards, right? With the largest Contentful Paint and details about like how they're measured are available as well here. With our largest Contentful Paint, we can just click and drag to highlight over our set of events that we care about.

So viewing that set of events, we have all our problematic largest Contentful Paint transactions here. With that, we can go into the details of an individual transaction. Those spans, just to relay back to the diagram we had earlier, these spans are these individual operations that we have listed out. So with our React app, we're automatically capturing some browser activity, resource loads, React mount activity. We also have with the distributed trace feature since we have Sentry incorporated in our other applications. We have those details, those transactions and their spans available to expand here from a single view. For our product transaction from our front-end application, we also have the web vitals specific to this event. So it's failing on the largest Contentful Paint, happened 10 seconds out of 10 and a half-ish seconds. And a lot of the time as we're reviewing this is happening on this one HTTP client operation. Tag details to help us understand a bit better about what's going on here and also a timeline of activities. These breadcrumbs help us figure out the user experience as well. Now with Sentry, since we have the application or the SDK on our back-end application and other related applications, we can from here expand out to understand the activity from the back-end. And here we have details on the database queries that happened during this transaction. We can figure out why it's taking so long. If we wanted to supplement the spans with more details to figure out more of what's happening, that is very important and helpful as well. But from this distributed trace, just wanted to also change the view for us to look at the full trace. So with this trace ID, remember where we have a single trace here, and in our case, we have six transactions happening. So our front-end application calling for other applications, in this case, our Python app.

And we also have within a Python application calling our Rails app. So we've got three applications similar to this diagram, and they're non-blocking. So these are happening asynchronously, not a problem. Going into the one that's taking the bulk of the time, we can view the transaction for that, see the same details we saw earlier from the breakdown of operation time, but now we have tag information about this Flask activity. So this is just another way to dive into the performance details that have been captured through Sentry.

Okay, so we've talked about Web Vitals, user misery score that led us to the transaction that we reviewed and also tags and breadcrumbs for additional context. One way to supplement a tag and data within a transaction, I'm just gonna go to this products join transaction that I've edited in my local app. I've added this information. So within that transaction, I've manually, so we can manually set spans and manually set data. So I've manually in this case, you can see the highlighted green, created a span with the operation called fancy operation with a new description, my new description, and I can supplement this span data, as you can see here with custom data, set custom data. So very verbose, but we can also add breadcrumbs in a similar way. So if we wanted to supplement the data that we're sending over to Sentry, that's available through the SDK as you see here.

Now, how is this represented on the Sentry side? Let's take a look. So on my React app, let's just go to all the transactions to find our products join operation. We have all of them listed out, all two. So not very helpful, right? But it's our local app, it's no big deal. So here we have our fancy operation as we talked about. So that's this where we can manually update the operation details and description details, even if we've received it from an automatic instrumented span. So we can always edit them. We can update the details and we can also supplement the data within it. So I've toggled on this fancy operation, if you can see here. And we have details accordingly with the tags that we've set. And that's how this is represented. And also the custom data we've added within the span. And this helps, so as developers, we can click through individual spans to understand what's going on and also supplement them specifically. We can also supplement the transaction with tags as well. We talked about adding breadcrumbs. So with that, we have in my app, I added a custom category, custom cat with a marker of some routing. So as we're working through our application here, if we wanted to supplement some more timeline activity, that's available through the breadcrumbs. So we have marker of some routing in our breadcrumbs.

Now, just to take a quick detour, I wanted to also, because this is top of mind, I did a workshop with monday.com last week, and they have this spectacular blog post, which I highly recommend and I'll share out after this meeting as well, where they talk about how they've used Sentry and incorporated tags in breadcrumbs that have been useful for them. So in their case, they've added tags on the issue side. So just going back to an issue, they've added their own set of tags, right? We have a custom tag, customer type, but they've added their own that have been useful for them. In their case, feature flags were really useful, tier type as well to help divide up the issues and organize them by tiers and last action. So this is just to inspire, I suppose, like how you can incorporate tags that are useful for your team or unique to your organization, whatever.

Now, the next thing I just wanted to highlight for us is building a meaningful timeline, because we just talked about adding those custom breadcrumbs, right? So custom breadcrumbs, oh, we have breadcrumbs on our issue side as well. So our breadcrumbs here, the timeline of activities that led up to the error, which is also filterable by different types of activities. So if we wanted to understand the user from the user experience, you can look at like the UI clicks where they navigated to and from, the fetch calls that also happen kind of behind the scenes leading up to the error. So this timeline of activities, we can also supplement with our own breadcrumbs. So that's detailed out here. For Monday, they liked last event, last websocket event pushed, some more Redux action details, analytics events, but you can add your own and that sequence of timeline can help troubleshoot and triage, debug, et cetera.

Okay. So I think this is a good stopping point. I just want it to, because we've already talked about distributed trace, the navigator will go in and connect the dots for error. But so I wanted to also trace errors from the front end to the back end. That's the whole premise of this meeting anyway, so let's just do that. So we've got the front end and the back end that we already traced through, but now that we've talked about performance, let's look at the full trace. So remember we have that unified trace ID, and within this trace, we have two transactions and two errors happening during that experience. We can view the transactions as we did before to see the operation breakdown, supplement it with spans, if we'd like, as we talked about. We can also see where the error happened during the transaction. Toggle from the transaction, as we have here, to the error, and then go from the error to the backend error or error to the backend transaction. So it's all available on the Sentry side from this unified one view where we can go from the transactions and the errors that are happening alongside them. So that's my trace errors portion that I wanted to definitely drill home for us. And that's with that distributed trace feature that we've got. Cool. Now, let me continue on with alerts. So remember we went back in time, we've set up our Sentry on our publicly hosted application, and also I set up alerts for us. So the alert that I've got for us was similar to what we reviewed together, that issues alert. Let's reproduce, well, we produced this together already through the alerts page. So we can create an alert, we can create more alerts off of these different types of suggested alerts with examples as well.

So there's a lot of variety we can play around with here. But for the issues alerts site, instead of that very basic, when a new issue is created, we can also consider cases where the number of events in the issue is, let's say more than a certain amount in an hour. We can also add on to that with other criteria. So number of events of an issue is a percentage base higher, let's say, in one hour compared to another time period ago. So these are all configurable, so if there are spikes in your application, we can certainly notify off of that. As we add more triggers, as we call it, we can do an AND or an OR operator off of that. We can also do the same off of the filters. So we can do AND, OR, or NOT operators off of that. Be very granular in this sense as well. So if let's say, the environment, we only care about the environment where it's a production, things like that. We can add filters off of this, and we can also perform different types of actions. We showed a Slack notification, but we also integrate with other notification platforms like PagerDuty, Teams. We can also create a JIRA issue immediately when these triggers and filters would hit this alert as well. So we have criteria on how that would work. Details on our integration with issue link settings that are set within our integration can be configured here.

Just to detour a little bit on the integration side, they're all listed out in our org's integration page. With JIRA specifically, there's two-way binding, and just note there's JIRA and JIRA Server. So that's like the hosted versus on-prem versions. So with the configurations we set up, there is two-way binding in terms of what's happening on the Sentry side and what activity would be happening on the JIRA side. So this is how it would sync. I'll share the details out after the meeting on our, we have a docs page for this as well. So that's on the issues type of alert.

We also have metric-style alerts. So if there is activity, let's say going back to our performance activity on, let's go to our more interesting project, actually. If there's some performance activity off of, let's say the product side that we want to care about, we can do it through a throughput, so how frequently certain transactions are hitting our hitting Sentry, or we can also create an alert off of transaction duration if things are taking a very long time. So just going back to the products transaction that was, you know, very slow, we can do a P95 over let's say five minutes just to get more specific data points here. And if things are above a certain number of seconds, let's say eight seconds, above eight seconds is critical, seven to eight seconds is warning, under seven seconds can be resolved. So those thresholds would be highlighted over our kind of preview graph here. We can set the preview graph to a different time period as well. We can also set a percentage change similar to what we talked about earlier.

So if things are spiking, then we can be notified off of that, get some actions going. So under different thresholds, we can notify accordingly. So an example of how that would look is represented in the alerts that I have here. So when we go from a warning threshold to a critical threshold, that's we're alerted in this way, or if we're resolved, we're also alerted. This is through Slack, but we can also set up these alerts through email and they would look the same with the color coding as well. So that's on the alert side with the documentation page specifying all the criteria and how granular we can be with the different types of notifications. So I'll share that out.

Also wanted to talk about releases. So this is how we can certainly pay attention to how well our different versions of our app is performing. We've got details on associated commits that have been happening through integrations with our source control management. So what commits happen there? And, oh, let me just enable this. What commits happen there? What files have changed as well? And issues and transactions associated with specific releases. So let's take a look at how that's represented in Sentry.

So with our releases, that's in our Releases tab, detailing different versions of our code that have been deployed. We can sort by different release versions. So this is, we do support semantic versioning and you can do like 22.X or whatever, organized by different environments that have been set across a certain time period, displaying off of session information. So as users are interacting or interacting with your application, we send up a session to determine that crash free rate. So during their experience, if there were no crashes, so that's no uncaught errors or exceptions, then that would be crash free, good. So we've got details across the past 24 hours to see the adoption rate there, and also across let's say the past two weeks. So in the past two weeks, 49% adoption on this 22.3.3, 51%, 22.3.2. Now jumping into a release, just to kind of map back to our slide here, we've got details on commits, files changed, and the issues accordingly. So commit information detailed here, who committed what, quick links to our GitHub with our repo, files changed as well, to know what files were changed for this specific release, and also the health of this release in the different perspectives I suppose. So crash free session rates, failure rates, et cetera, other types of curated graphs that are helpful, comparing this release against all releases through kind of this overlaid graph, some information on what authors were making the most commits, and also our issues for this specific release version as well.

With the issues, we've already talked a bit about all the data that we captured through an issues page. I also wanted to take this opportunity to go into issue states, and that's an important part of Sentry to keep organized with the status of our issues. So when they come in, they're marked as unresolved, as our developers are fixing it, we can, once they've sorted it out and don't think it'll come back again, they would mark it as resolved. Now, if the issue comes back again after being resolved, so regression, issue seen again, that means it would be listed as a regressed issue. So that's how we keep organized and help guide our end users with what to pay attention to, especially on the regressed side. Okay, I know we just have eight minutes left and I just got a few more topics to breeze through, so just thank you for bearing with me here. I also wanted to talk about Discover and dashboards. So I've got two examples for us to go through, one of which is understanding errors for our enterprise level customers, and we wanna understand these errors in the context of browsers, right? So to do this, what we have is our Discover query. So that's our, it's a query platform to slice and dice data that we've captured through Sentry. Now going into that, we have some pre-built Discover queries that I can toggle. Going into the errors by title, that's like a way to start off our Discover query, so to speak. We can organize by several or one or many or all our projects to slice and dice the data from, filter by environments as well, or time period. Now, with the prompt, we are looking for errors for enterprise customers organized by browser. So this is just an example for us to take a look at.

We have our customer type tag, and you can have your own tags as we talked about earlier. So let's add that. I type, I click that in, that added it as a filter. Also, we can bang customer type on enterprise, and that'll basically give us everything that's not enterprise. So that's available as well.

In any case, just going back to the prompt, enterprise users, and we want to know the distribution of these errors by browsers. So let's do that together. We have our browser, we have a browser name, and we also can make a count off of that. So let's apply these columns and that'll update our result set. And we know just off of the past 24 hours, this is our breakdown of the errors for our enterprise customers based off of their browsers. If we like what we see, we can always add it to a dashboard as we call it. So that's an aggregation of these discover queries. And we can also dive deeper into a result set, take a look at that grouping, group them, add more columns, whatever, but eventually make our way into the event details, go back to the trace as we've reviewed before together, go into the errors, go into the transaction, et cetera. So that's just one example. And I know we just have five minutes left. So I'm actually just gonna pass up on the second example. We can talk more about it, and also I can kind of guide you all through, you know, details on a followup email here.

But for dashboards, let me jump into our dashboard tab here. As I mentioned, it's an aggregation of discover queries that we've saved to it. This is very dynamic and can be set up like per team or per organization or per person even. So it's whatever data that is relevant to you or whomever and organized and visualized rather in unique ways where behind the scenes is a discover query. And we can also change the visualization from a number to a chart or a graph, et cetera. So that's on the discover side. It's the events table data, which you can save what you love and visualize it in different ways.

We have like pretty discover queries gathered together in dashboards that we help our users with. So figuring out what's unique to you or what's helpful to you. We're happy as solutions engineer to figure that out together. Great. Last couple of things I wanted to do together, it looks like this is a little buggy, is talk about the sandbox to let you all have a play with Sentry without needing to go into setting it up all as we've done together. Although it's not too complicated, but an easy way to get started with Sentry is also to just go into Sentry.io. I'm in incognito mode. You can go into sandbox. And from here, you can play around with the issues as we've talked about the performance side that we've also looked at together. Discover and dashboards are a lot of fun to just poke around with, understand different, I guess, perspectives of errors and transactions and ways to slice and dice as we've talked about. So that's available just from the Sentry.io page and the sandbox button here. So I'll share those details out as well. Now, my slide deck has frozen, but that's basically the gist of it.

We've got a few minutes for questions here and last but not least, I was told that we have this page to leave you with. So if you want to get started with Sentry, feel free to go to Sentry.io slash sign up and follow up with us there. Now, sorry about that. I've got a few questions in chat. Perfect. So I'll get to these. I know we just have a couple minutes left. So 4lex or Alex is asking, is it safe GDPR wise to use Sentry currently in the EU since it's a US company? Yes, it is. So we have specific responses. We are GDPR compliant, and we have ways to scrub data.

So we have data scrubbing tools on the application side and on the server side to make sure sensitive information like personally identifiable information is not even sent into Sentry or not persisted in Sentry either. But we are GDPR compliant, so that's all good.

Hello, can you, okay, so this is Mohamed. Hello, can you please share your GitHub link? Oh, perfect, yes, I will send that. So that's the application monitoring and power plant demo that we went through together. I can certainly share that at the follow-up.

Okay, can, all right, so the next question by Daniel A is, can see attack errors against the app, attack errors, do you integrate with another security platform to filter the errors in the right category? I can see the scope of the current settings, just need to see what is the approach on it. Okay, so this is interesting. I'm not sure if I understand completely, but when it comes to issues that we have in Sentry, they are grouped together through stack trace as you can see here with our like 39,000 events that have been aggregated together. It's through the stack trace originally, but if we wanted to adjust the issue grouping rules, that's available to maybe only consider like the first frame or the second frame or a certain number of frames or remove the fingerprinting rule to how we grouped them together and just look at the error message. So we group by error message. There are different ways to aggregate these issues together or these errors together.