Putting Sentry into Context

Imagine you created a nice application for other people to use. Your product is gaining traction, new users start flowing in and you start earning some money. Life is great and you decide to roll out a big update you have been working on. But after a few days of the release, engagement rates and sales seem to drop and you are not sure why: all of your automated tests pass and you have extensively tried your app on your machine. A little panicked, you start investigating. You are still very lost when an email comes in: a kind user took the effort to submit a bug report! The bug report is very vague, but at least you have a sense of what is happening. You finally find the culprit after another day of work: three lines of code in the backend that caused unexpected behavior in the frontend. Almost a week later, you fixed the issue and users are slowly returning to your app.

Now let’s look at the same scenario if you would have used Sentry. Again you’ve rolled out a big update and life is great until you get a notification from Sentry saying that a fatal issue is occurring for multiple users. Using Sentry’s cross-stack tracing, you trace the error to the backend where the breadcrumbs and stack trace immediately show what is wrong. Two hours after the first report, you have deployed an update.

Sentry automatically reports exceptions, giving developers insights into bugs with as much detail as possible by providing session information like events leading up to the error or user device information which can even include the state of the processor. It supports error monitoring for a wide variety of languages and frameworks and it keeps track of errors related to different versions of your code and gives you one dashboard to look through, filter and analyze reported errors. Sentry removes the guesswork and reproducing issues becomes easy as developers can use the reported information to understand where and how the error occurred. In order to fully understand Sentry as an open source project, we will first put the software into context in this essay.

End-user mental model

The end-user mental model consists of two parts. The first part, the what-the-system-is, is about what the end-users see when using Sentry and it describes the form of Sentry¹. Once the end-user, a developer, installs Sentry with the appropriate SDKs, Sentry starts to monitor all exceptions automatically in real-time that are occurring in the application of the end-user. It detects and groups individual errors into single larger issues. An overview of this is shown to the user in the Sentry dashboard. Sentry provides a separate overview for each error with information about for example its impact, the stack trace and the context of the states of the system².

The second part, the what-the-system-does, is about how end-users use Sentry when they are interacting with it and, therefore, it describes the functionality¹. The end-users can automatically create new issues for errors in their code repository, such as GitHub, using the Sentry dashboard. Sentry analyzes and assigns the most suitable engineer or team for each issue that needs to be solved based on the integration with the code repository. Users can also trace specific errors through their whole codebase as Sentry supports a combined analysis of the front-end and the back-end code. Finally, developers can analyze the history of the monitoring data using different metrics such as the number of affected users, the number of events or the number of errors for each release². An overview of the what-system-is and the what-system-does is presented in the image below, showing a visual version of the end-user mental model as described by Coplien and Bjørnvig¹.

Key capabilities and properties

From the characterization and mental model above, we can derive a list of key capabilities and properties of Sentry:

• Open-source
• Real-time error and application monitoring
• Support for all major languages and frameworks for a wide appeal
• Integration with other applications and services (GitHub, Slack, and more)
• Error tracing with breadcrumbs and state information
• Security and privacy, using industry-standard technologies³
• Easy-to-use

Stakeholder analysis

In order to get an overview of the parties with an interest in Sentry, we conducted a stakeholder analysis. We categorize these stakeholders in the categories introduced by Rozanski and Woods⁴. Since it seems to be the case for Sentry that most of their developers are also maintainers and testers, we combine these stakeholders in the developers category. We also left out the production engineers and system administrators classes since Sentry is an open-source project. However, the Sentry team working on the SaaS version likely has these stakeholders. One could also consider competitors to be stakeholders⁵, thus we include them for sake of being thorough.

Now that we have identified the stakeholders, we can prioritize them using a Power-Interest Grid in order to gain more understanding of the relationships with these stakeholders⁷.

The current and future context

The context of a system describes the relationships and dependencies between the system itself and its environment⁴. The context of Sentry is visualized in the Context Model below.

This context model is not exhaustive since there are for example more languages for which Sentry provides an SDK. The following relationships can be seen in the model:

• Dependencies: Like stated before in the stakeholder analysis, Sentry has numerous dependencies which include libraries and frameworks like Django and React, database systems like PostgreSQL, and other tools like Docker.
• Development: Sentry is developed using GitHub for version control hosting, Travis CI for Continuous Integration and Deployment, and Percy for visual testing. The backend of Sentry is written in Python while the frontend is written in JavaScript and TypeScript.
• Integration: Sentry provides client SDKs that send errors to Sentry for almost all frequently used programming languages and frameworks, a selection of which are shown in the Context Model. Furthermore, Sentry features integrations that allow users to track errors and issues across multiple platforms, like Jira, Slack, and Datadog.
• Users: Sentry has many users, including some large companies like Microsoft, Cloudflare, and Airbnb.
• Competition: Some other companies provide error tracking as a service, like Rollbar, Bugsnag, and Raygun. These services are however not open-source.
• Investors: As already mentioned in the stakeholder analysis, Sentry has investors including Accel and NEA.

Product roadmap

At the time of writing there does not seem to be a roadmap available for the Sentry project, neither on Sentry.io, the GitHub project nor on the Sentry forums. The latest version of the on-premise version (10.0.0) was released on the 7th of January 2020.

Based on an inquiry with David Cramer, who is the founder and CTO of Sentry, we found that the Sentry team operates in the short term roadmaps with some long term goals in mind. The primary goals for Sentry at this point being to support every runtime and to move into the broader space of application monitoring (also APM). In the shorter term, they are therefore working on improving the experience for developers for platforms where you are not in control of the device itself like mobile, browser and desktop. Next to that, they are working on the functionality required to move into application monitoring like expanding upon distributed-tracing to track events across different elements of your application like frontend and backend.