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 Sentry1. 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 system2.
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 functionality1. 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 release2. 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ørnvig1.
Key capabilities and properties
From the characterization and mental model above, we can derive a list of key capabilities and properties of Sentry:
- 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 technologies3
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 Woods4. 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 stakeholders5, thus we include them for sake of being thorough.
|Acquirers||Sentry’s senior management. This category also includes Sentry’s investors: Accel and NEA and angel investors like Nat Friedman, Ilya Sukhar, and Greg Brockman.|
|Assessors||Assessors ensure that the system satisfies legal requirements and standards4. We were not able to identify stakeholders with this role.|
|Communicators||Sentry’s communication happens through various channels, including their blog, Twitter, Forum and GitHub. Since Sentry is a company, most if not all of their employees can be considered communicators (i.e. the core team).|
|Developers||The main Sentry repository on GitHub has 430 contributors at the time of writing. Most top contributors are Sentry employees, and we consider these people to belong to the core team.|
|Suppliers||Like many other large software projects, Sentry has numerous dependencies on which they build their platform and thus can be considered suppliers. Examples include: Django, Docker, PostgreSQL, etcetera.|
|Support Staff||If you just want to use the open-source version of Sentry, support is relatively limited (e.g. through their forum). However, if you make use of their SaaS solution, you have access to Sentry’s support team.|
|Users||Sentry has roughly two types of users: those who use the open-source version to host Sentry on-premise, and those who pay Sentry for their SaaS version. Sentry has many big users like Microsoft, Uber, Airbnb, and PayPal6.|
|Competitors||Sentry operates in roughly two markets: error monitoring and application monitoring. There are various competitors in these fields such as Rollbar, Bugsnag and Raygun.|
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 stakeholders7.
The current and future context
The context of a system describes the relationships and dependencies between the system itself and its environment4. 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.
- 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.
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.
Archer, G. R. (2006). Six Good Reasons to include competitors as stakeholders. Available at SSRN 1437117. ↩
MindTools. (n.d.). Stakeholder Analysis. Retrieved March 3, 2020, from https://www.mindtools.com/pages/article/newPPM_07.htm ↩