Key Terms

The key terms and concepts defined on this page are the fundamentals of Sentry. While we define new terms as you come across them throughout our documentation, having an understanding of the key concepts and features here will make it easier to learn more complex ideas about the product.

This list is ordered so that each definition builds on the previous ones.

Key Concepts

Some of the following key concepts have corresponding features with the same name listed (in upper case) in the Key Features section.

  • Sentry SDKs - Sentry's programming language/framework-specific libraries for application monitoring. When you add one of our SDKs to your application, event data from your application is captured and sent to Sentry, so we can provide you with error and performance reports.

  • sentry.io - Sentry's user interface for

    SaaSSentry's cloud-based, software-as-a-service solution.
    customers, where event data captured by our SDK is visualized. (For self-hosted users, the user interface is on an internal domain for your company.)

  • event - An error or a transaction.

  • error - What counts as an error varies by platform, but in general, if there's something that looks like an exception, it can be captured as an error in Sentry. Sentry automatically captures errors, uncaught exceptions, and unhandled rejections, as well as other types of errors, depending on platform.

  • attachments - Stored additional files, such as config or log files that are attached to an error event.

  • issues - An issue is a grouping of similar error events. Every error event has a set of characteristics called its

    fingerprintThe set of characteristics that define an event.
    , which is what Sentry uses to group them. For example, Sentry groups events together when they are triggered by the same part of your code. This grouping of events into issues allows you to see how frequently a problem is happening and how many users it's affecting.

  • transaction - A transaction represents a single instance of a service being called to support an operation you want to measure or track, like a page load, page navigation, or asynchronous task. Transaction events are grouped by the transaction name.

  • data - Anything you send to Sentry. This includes, events (errors or transactions), attachments, and event metadata.

  • project - A project represents your service or application in Sentry. You can create a project for a particular language or framework used in your application. For example, you might have separate projects for your API server and frontend client. For more information, check out our best practices for creating projects. Projects allow you to associate events with a distinct application in your organization and assign responsibility and ownership to specific users and teams within your organization.

  • DSN - Data Source Name. A DSN tells the Sentry SDK where to send events so the events are associated with the correct project. Sentry automatically assigns you a DSN when you create a project. Learn more in our full DSN documentation.

  • team - Teams are associated with your Sentry projects, and their members receive issue notifications, in addition to becoming issue owners. Learn more about setting up teams.

  • environment - environment is a Sentry-supported tag that you can add to your SDK that's intended to refer to your code deployments' naming convention, such as development, testing, staging, or production. Environments help you better filter issues and transactions among other uses. Learn more in our full Environments documentation.

  • release - A release is a version of your code deployed to an environment. When you notify Sentry about a release, you can identify new issues and regressions associated with it, confirm whether an issue is resolved in the next release, and apply source maps. Learn more in the full Releases documentation.

  • release health - Release health data provides insight into the impact of crashes and bugs as it relates to your user's experience and reveals trends with each new issue. Learn more in the full release health documentation.

  • performance monitoring - Performance monitoring is the act of tracking application performance and measuring metrics such as how many transactions are being sent and the average response time for all occurrences of a given transaction. To do this, Sentry captures distributed traces consisting of transactions and spans to measure individual services, as well as operations within those services.

  • alerts - Alerts let you know about problems with your code in real-time by sending you notifications when certain alert rule conditions are met. There are several types of alerts available with customizable thresholds and integrations.

Key Features

Each of these key features in sentry.io is represented by a page (or set of pages) in the application.

  • Projects - Lists the projects of which you're a member, by team, and provides you with a high-level overview of your projects. From here, you can go to the Project Details page of each project for a more granular view. Learn more in the full Projects documentation.

  • Issues - Displays information about grouped errors in your application. From here, you can go to the Issue Details page for a more granular view of any issue. Learn more in the full Issues documentation.

  • Performance - The main view in sentry.io where you can search or browse for transaction data. The page displays graphs that visualize transactions or trends, as well as a table where you can view relevant transactions and drill down to more information about them. Learn more in the full Performance documentation.

  • Releases - Provides a high-level view of each release version, the associated project, the adoption stage of each release, the authors of each commit, as well as release health data including the percentage of crash-free users, and the percentage of crash-free sessions. You can navigate directly to the Releases page or from the Issue Details page, by selecting release ID listed under "Last Seen". Learn more in the full Releases documentation.

  • Alerts - Where you can create new alert rules and manage existing ones. Learn more in the full Alerts documentation.

  • Discover - Allows you to query events across environments, providing you with visibility into your errors and transactions and unlocking insights into the health of your entire system. The Discover page visualizes the results of queries. Learn more in the full Discover documentation.

  • Dashboards - Provide you with a broad overview of your application’s health by allowing you to navigate through error and performance data across multiple projects. Dashboards are made up of one or more widgets, and each widget visualizes one or more Discover or Issues queries. Learn more in the full Dashboards documentation.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").