A series of

  • 1 minute Quick use of The latest version of Docker Sentry-CLI – create version
  • Quick use of Docker start Sentry-CLI – 30 seconds start Source Maps
  • Sentry For React
  • Sentry For Vue
  • Sentry-CLI usage details
  • Sentry Web Performance Monitoring – Web Vitals
  • Sentry Web performance monitoring – Metrics
  • Sentry Web Performance Monitoring – Trends
  • Sentry Web Front-end Monitoring – Best Practices (Official Tutorial)
  • Sentry Backend Monitoring – Best Practices (Official Tutorial)
  • Sentry Monitor – Discover Big data query analysis engine
  • Sentry Monitoring – Dashboards Large screen for visualizing data
  • Sentry Monitor – Environments Distinguishes event data from different deployment Environments
  • Sentry monitoring – Security Policy Reports Security policies
  • Sentry monitoring – Search Indicates the actual Search

directory

  • Introduction of alarm
    • Error Issue alert
    • Error and performance indicator alerts
    • Create alerts
    • notice
  • Alert type
    • Issue warnings
    • Indicator alarm
      • Alarm details
  • Create alerts
    • Issue Alert configuration
      • The environment
      • team
      • Name of the alarm
      • “When” condition: trigger
      • “If” condition: filter
      • “Then” condition: action
        • The Issue owner
        • Team Slack notifications
      • Action interval (rate limit)
      • Project level alert Settings
        • Abstract
    • Indicator alert configuration
      • The filter
        • The environment
        • The event type
        • Tags & Attributes
      • Index (function + time interval)
        • Alarm function
        • The time interval
      • The threshold value
        • Automatically solve
      • action
      • Rule name
      • team
    • Alert routing with integration
      • integration
        • Slack alarm
        • PagerDuty alarm
        • Microsoft Teams alert
      • Build your own integration
      • Legacy integration
    • Alert best Practices
      • Detect important issues
      • Reduce alarm noise
        • Has neglected Issue
      • routing
  • notice
    • Workflow notification
    • Deployment notification
    • Notice the quotas
    • Weekly report
  • Personal Notification Settings
    • The alarm
      • delivery
    • workflow
      • delivery
      • unsubscribe
    • Email routing
    • Weekly report
    • The deployment of
      • delivery
    • My activities

Introduction of alarm

Alerts provide real-time visibility into code issues and their impact on users. There are several types of alerts available for custom thresholds and integration.

From the Alerts page of sentry. IO, you can create new alert rules and manage existing rules. The Alert Rules TAB displays your existing Alert Rules, along with their current status, project, team, and creation date. By default, this list is filtered so that only alerts that are relevant to the team you belong to and are not relevant to any team are displayed. You can change this setting using the filter button.

The Alerts page also displays a History TAB where you can find a list of indicator Alerts with information such as when they were triggered and when they were active.

Error Issue alert

An Issue alert is triggered whenever any problem in the project meets the specified criteria. You can create alerts for Issue level changes, such as:

  • newIssue
  • IssueIncreased frequency
  • Resolved and ignoredIssueBecome unsolved (unresolved)

You can find the full list of Issue alert triggers in the Issue Alert configuration.

  • Docs. Sentry. IO/product/ale…

Error and performance indicator alerts

Metrics alerts are triggered when metrics are violated by error or Transaction events. Use metrics alerts to monitor a limited and known set of metrics and components that you care about, such as error frequency or performance metrics across a project, on important pages, or with specific labels.

Create alerts to monitor metrics such as:

  • Total errors in the project (Total errors)
  • Delay (Latency) : minimum value (min), maximum value (max), average value (average), percentile (percentile)
  • Failure rate (Failure rate)
  • User-defined Indicators

You can find a complete list of available metric alerts in metric Alerts.

  • Docs. Sentry. IO/product/ale…

Create alerts

You can select the default Issue alert when creating a new project in Sentry. IO. However, you can also use these best practices as a guide to create your own alerts to meet your team’s needs.

  • Docs. Sentry. IO/product/ale…
  • Docs. Sentry. IO/product/ale…

notice

In addition to alerts, Sentry sends you notifications about various matters, such as issue status changes, published deployment, and quota usage. You can fine-tune these Notifications, as well as your personal alert Settings, in User Settings > Notifications. Learn more about notifications and tuning their associated Settings in the full documentation.

  • issue state changes: Docs. Sentry. IO/product/iss…
  • Release deploys:Docs. Sentry. IO/product/rel…
  • Quota usage:Docs. Sentry. IO/product/acc…
  • Docs. Sentry. IO/product/ale…

Alert type

You can create two types of alerts:

  1. Issue alerts: whenissue(a group of error events) triggered when a specific condition is met.
  2. Metric alerts: whenerrortransactionEmitted when the macro indicator of an event exceeds a specific threshold.

Issue warnings

An Issue alert is triggered whenever any issue in the project meets the specified criteria. For example, these standards might be re-emerging resolved issues or issues that affect many users.

In the Alert Rules TAB, these alerts are identified by issues ICONS, and by default, they appear at the bottom of the list of alerts. (If you have multiple metric alerts, this may push your issue alerts off the first page of the list.)

In problem alerts, Sentry evaluates configured alert conditions each time it receives a new event. The alarm condition consists of three parts:

  1. The trigger (Triggers) specify the type of activity you want to monitor, or when (When) should trigger the alarm.
  2. Filters (Filters) pass only inissueAn alarm is triggered when specified criteria are met to aid controlissueNoise.
  3. And then,ActionsSpecifies what should happen when the trigger condition is met and the filter matches.

Indicator alarm

Metrics alerts tell you when metrics exceed thresholds, such as spikes in the number of errors in a project, or changes in performance metrics, such as latency, Apdex, failure rate, or throughput.

Metric alerts monitor macro metrics for error and Transaction events. Metrics take a set of events and use functions (such as count() or AVg ()) to calculate aggregate values that should be used for event attributes over time. When creating metrics alerts, you can filter events by attributes and tags, which is particularly useful for aggregating events that are not grouped into a single issue.

These alerts use Critical and Warning triggers to measure severity. The current state of the alert is the highest severity trigger that is active and can be one of three values: Warning, Critical, or Resolved. Sentry notifies you whenever the status of an alert changes.

When creating an alert, all alert types displayed (except “Issues”) can be used to create indicator alerts:

  • Number of Errors
  • (1) The Users Experiencing Errors
  • Throughput
  • Transaction Duration
  • Apdex
  • Failure Rate
  • Largest Contentful Paint
  • First Input Delay
  • Cumulative Layout Shift Cumulative Layout Shift
  • Custom metrics

Alarm details

By default, the Alert Details page displays a history of indicator Alert rules for the past 24 hours, but you can change the time period using the Display drop-down menu. When an alert is triggered, clicking on the notification you received takes you to this page, which shows the time period during which the alert is active. The page also includes details such as alert rule conditions, the current state of the alert, and a summary of the time the alert spent in each state (Critical, ‘Warning, or Resolved’).

The Alert Details page also includes a list of suspicious issues or transactions related to metrics to help pinpoint the root problem more quickly. You can look at what might be causing the alarm to trigger, and then open the metric in Discover to find more information.

  • Docs. Sentry. IO/product/dis…

Create alerts

The minimum role required to create an alert is member. Sentry users with Manager or owner permission can choose Settings > General Settings > Let Members Create and Edit alerts (Settings > General Settings > Let Members Create and Edit) Alerts) change the minimum role requirements.

To create an alert:

  1. Navigate to theAlarm (Alerts)And click the"Create Alert Rule".
  2. Select your project.
  3. Select what you want to be alerted to. choose"Issues"Will createissueAlerts while selecting any other option will be createdmetricThe alarm.
  4. Click on the"Set Conditions".
  5. On the Alarm Configuration page, set alarm conditions:
    • Issue Alert configuration
      • Docs. Sentry. IO/product/ale…
    • Metric Alert configuration
      • Docs. Sentry. IO/product/ale…

Issue Alert configuration

Sentry provides several configuration options to create issue alerts based on the needs of your organization.

The environment

Specifies which environments will use this particular alert rule. This control filters environment labels in events. This filter is useful, for example, because the urgency and workflow you apply to production alerts may differ from the urgency and workflow you apply to alerts originating in QA environments.

The “Environment” drop-down list here has the same Environment (excluding hidden environments) available to the selected item in the global “Environment” drop-down list. Choosing All Environments is equivalent to having no environmental filter.

team

You can select the team to associate with the alert so that members of that team can edit the alert. Note that this association can only be made if you are a team member. If no team is selected, anyone can edit the alert.

Name of the alarm

Specify a descriptive name for your alert, such as the affected team and the subject of the alert. For example, Frontend Latency, Backend Failure Rate, or Billing Apdex.

“When” condition: trigger

The “When” condition or trigger specifies what type of activity you want to monitor for the issue:

  • For the first time
  • Move the state from resolved (resolved) changed to unresolved (unresolved)
  • Change the state from ignored (ignored) changed to unresolved (unresolved)
  • To see more than a certain number of times in an interval
  • Be seen by more than a certain number of unique users at an interval
  • aissue{time}The internal influence exceeds{X}%The session
    • The percentage of sessions affected is an approximation calculated asissueThe ratio of frequency to the number of sessions in the project
    • Only if the number of sessions in the past hour exceeds50Will trigger a percentage-based alert

Triggers is optional. If you do not select a trigger, the “When” condition is assumed to be satisfied by default. In other words, all events satisfy this condition.

Learn more about Issue status in Issue States & Triage.

  • Issue States & Triage: Docs. Sentry. IO/product/iss…

“If” condition: filter

Sentry checks “if conditions” or filters after the “When” condition is satisfied, which helps control noise by filtering out problems that do not meet your specified criteria. You can filter issue or event attributes. If an event filter is specified, it only checks for the event that triggered the alert, for example:

  • issueOlder or newer than a specified duration.
  • theissueAt least it happened{X}Times.
  • issueAssigned to {no one/a team/a member}.
  • The event comes from the latestrelease.
  • The event{attribute} {matches} {value}. Matching type: equal to (equals), is not equal to (does not equalBegin withstarts withEnd up in (ends with), including (contains), excluding (does not contain), set (is set) or not set (is not set).
  • The event{tag} {matches} {value}. Matching type: equal to (equals), is not equal to (does not equalBegin withstarts withEnd up in (ends with), including (contains), excluding (does not contain), set (is set) or not set (is not set).
  • Event Level{matches} {level}. Matching type: equal to (equal to), less than (less than) or equal (equal to), or greater than (greater than) or equal (equal to).

Learn more about tags and Event Attributes.

  • Tags:Docs. Sentry. IO/platforms/j…
  • The event attributes:Docs. Sentry. IO/product/sen…

“Then” condition: action

“Then conditions” or actions that specify what should happen when trigger and filter conditions are met:

  • To the problem owner (Issue Owners), team (a team) or members (a member) send notifications.
  • Send notifications to the integration, which can contain the following options, depending on which integration you install:
    • sendSlacknotice
    • sendPagerDutynotice
    • sendMicrosoft Teamsnotice
    • Send notifications to all old integrations.
    • Send notifications using integrations built on the integration platform
  • Create one for the integrationissue, including:
    • Jira
      • Docs. Sentry. IO/product/int…
    • Azure DevOps
      • Docs. Sentry. IO/product/int…

Learn more about alerts through integrated routing.

  • Docs. Sentry. IO/product/ale…
The Issue owner

Issue owners can be notified when an alert is triggered (email only).

For early adopters, these notifications are received via email or Slack, depending on the notification Settings of the problem owner.

  • Issue market metrix:Docs. Sentry. IO/product/iss…
  • Notification Settings:Docs. Sentry. IO/product/ale…

If the issue owner is not configured or found, the notification will not be sent or sent to all Project members, depending on the following Settings in [Project]>Settings>Issue Owners ([Project]>Settings>Issue Owners).

Team Slack notifications

Teams can configure Slack Channels to receive alert notifications. This can be done by typing/Sentry Link Team into the desired Slack channel. To see the Slack channel associated with a Team in sentry. IO, navigate to Settings>Team >[Team]>Notifications (Settings>Teams>[Team]>Notifications).

Action interval (rate limit)

Action intervals or rate limits control how often alert rules are triggered for a particular problem. If the alert condition matches the problem, Sentry only performs actions that have not been performed for the problem within the rate limit period. For example, if a problem satisfies alert conditions multiple times in a one-minute period, but your frequency threshold is one minute, you will only receive one alert.

The available intervals are:

  • Min:5.10.30.60
  • Hr:3.12.24
  • Day:7.30

Project level alert Settings

In [Project] > Settings > Alerts ([Project] > Settings > Alerts), you can configure the alert email subject template and summary Settings. Sentry users with owner, Manager, or administrator permissions or above can change these default notification Settings.

Abstract

The summary feature only works with issue alert emails (not notifications sent through integration) and, unlike the Action interval, limits the total number of alert emails sent for the project. This project-level setting allows you to control the minimum and maximum delivery intervals for alerts.

Indicator alert configuration

Sentry provides several configuration options to create metric alerts based on your organization’s needs.

The filter

The following filter groups are translated into Discover queries and displayed in the diagram at the top of the alert configuration page.

The environment

Specifies which environments will use this particular alert rule. This control filters the environment tag in the event. This filter is useful, for example, because the urgency and workflow you apply to production alerts may differ from the urgency and workflow you apply to alerts originating in QA environments.

The “Env:” drop-down list here is the same as the available environments (excluding hidden environments) of the selected objects in the global “Environment” drop-down list. If you select All, the environment filter is unavailable.

The event type

For some metrics alerts, you can set the type of event to receive alerts in the Events drop-down list:

  • event.type:error OR event.type:default
  • event.type:default
  • event.type:error
  • event.type:transaction
Tags & Attributes

Add filters in the fields provided to narrow down what you will be alerted to, such as URLS, tags, or other event attributes.

Index (function + time interval)

Depending on the type of alert you choose, you can select the functions and parameters to apply. In other cases, this feature is built into the alert and does not display Settings. For example, if you select “Number of Users Affected,” convert to the function count_unique(user.id). Because editing this function changes the nature of the alert, it is not editable and is therefore hidden.

Alarm function
  • count()
  • count_unique(...)
  • avg(...)
  • percentile(...)
  • failure_rate()
  • apdex(...)
  • count()
  • p50()
  • p75()
  • p95()
  • p99()
  • p100()
The time interval

Select the time period for evaluation indicators. Your choices range from one minute to one day. Sentry evaluates the specified window every minute. For example, if you specify a one-hour time window, Sentry evaluates:

  • At 3:00pm: 2:00pm – 3:00pm
  • At 3:01pm: 2:01pm – 3:01pm
  • At 3:02pm: 2:02pm – 3:02pm
  • .

The threshold value

Thresholds are values that help define alarm triggers. These values are marked as:

  • Critical (serious)
  • The Warning (Warning)
  • Resolved

You must set the Warning threshold so that it fires before the Critical threshold. When Sentry evaluates the alert, its status is updated to match the highest severity trigger. If you do not set the ‘Resolved’ threshold, the alert will be Resolved automatically when the ‘Critical’ or ‘Warning’ conditions are no longer violated. You can also resolve alerts manually.

Automatically solve

By default, a metric alert is resolved automatically when a specified metric no longer violates a Critical or Warning condition. However, you can set different resolution thresholds. For example, suppose your application’s normal error level is below 2000/ min, and you want to be alerted when it exceeds 5000/ min. You might want the alert to resolve only if the error level goes back below 2000/ min, not 5000/ min. By setting the ‘Resolved’ threshold in this way, if the error level falls back to just 4000/ min, even if it falls below the alert threshold, you will think there is a problem and the alert will not resolve.

action

Actions define how you and your team will receive alerts:

  • To the members (member) or team (team) Send an email. If sent to a member (team), members (team) personal project alert opt-out Settings (opt-out settings) will be covered.
  • sendSlacknotice
    • Docs. Sentry. IO/product/int…
  • sendPagerDutynotice
    • Docs. Sentry. IO/product/int…
  • sendMicrosoft Teamsnotice
    • Docs. Sentry. IO/product/int…
  • Send requests using internal integration.
    • Docs. Sentry. IO/product/int…

Learn more about alerts through integrated routing.

  • Docs. Sentry. IO/product/ale…

Rule name

Specify a descriptive name for your alert, such as the affected team and the subject of the alert. For example, Frontend Latency, Backend Failure Rate, or Billing Apdex.

team

You can select the team to associate with the alert so that members of that team can edit the alert. Note that this association can only be made if you are a team member. If no team is selected, anyone can edit the alert.

Alert routing with integration

By customizing alert rules and integrating the tools you already use, you can receive alerts when, where, and if you need them without interference. Alert notifications can be routed to Slack, multiple supported integrations, and custom integrations via Webhooks. When creating alert rules, you can use these integrations to configure who and how to be notified.

integration

Sentry’s integration gives you the option to route alerts through common applications such as Slack, PagerDuty, and Microsoft Teams. You can find these Integrations in Settings > Integrations and install them for the entire organization.

Slack alarm

Sentry Organization Owner or Manager can install and configure Slack integration in their Sentry account. After the integration is configured, the Issue alert rule will provide the following actions: send notifications to {channel} and display the tag {tags} in the notifications to the {workspace} Slack workspace. In the metrics alert, your Slack team will be available in one of the Action drop-down lists.

This Alert Action allows you to route alert notifications to selected channels in a Slack workspace (using the # prefix) or to specific users in direct messages (using the @ prefix).

Then, once you receive a Slack notification, you can update the problem in sentry.io directly from Slack using the ‘Resolve,’ ‘Ignore,’ or ‘Assign’ buttons.

PagerDuty alarm

Sentry organization Owner or Manager can install and configure PagerDuty integration in their Sentry account. After the integration is configured, the Issue alert rule will provide the following actions: send notifications to PagerDuty account {Account} and service {service}. In metric alerts, your PagerDuty account will be available in one of the Action drop-down lists.

Microsoft Teams alert

Sentry Organization Owner or Manager can install and configure Microsoft Teams in their Sentry account. After the integration is configured, the issue alert rule will provide the following action: send notifications to {team} teams to {channel(s)}. In the metrics alert, your Microsoft team will be available in one of the Action drop-down lists.

Build your own integration

If you want to route alert notifications to other solutions that Sentry does not integrate out of the box, you can use the Integration Platform. The integration platform provides a way for external services to interact with Sentry SaaS services using REST apis and Webhooks.

Sending alerts to Webhook is also helpful if you want to aggregate alerts from different monitoring systems or write custom rules to route alerts more intelligently.

When you create a new integration and enable the Alert Rule Action option on it, your integration will appear as a service when you choose to send notifications through the integration Action during issue Alert Rule creation. In metrics alerts, your integration is available in one of the Action drop-down lists.

Legacy integration

Legacy integrations (also known as plug-ins) are extensions to Sentry, packaged as Python libraries, and configured at the project level. To Send alerts to legacy integrations, select the “Send a Notification via an Integration” or “Send a Notification to All Legacy Integrations” action. You cannot route metrics alerts to legacy integrations.

Alert best Practices

It is important that alerts are sent to the right people at the right time. Sending too many notifications to too many people can cause them to be ignored. The following best practices will help you create or fine-tune alerts to minimize alarm noise while still telling you what you need to know.

Detect important issues

Frequency: Typically, you set up alerts to trigger when errors exceed a certain Frequency, but Frequency isn’t everything: If a low-frequency error is in a more important part of your application, it may be more important than a high-frequency error.

Users affected: Sometimes a very small number of Users produce a large number of errors, so alerting affected Users may be more important than the frequency of errors. However, not all errors with user counts in Sentry may actually be user-facing, and vice versa. If you filter these types of problems, you can avoid being alerted to errors that non-users face.

Tags: Use Tags to classify errors. For example, you can filter automatically captured URL tags to identify business-critical pages, or filter custom tags (such as customer_type) to handle these alerts more importantly. You can find a list of Tags available in your Project under [Project] > Settings > Tags ([Project] > Settings > Tags). The list is an aggregation of all tag keys (default and custom) encountered in the project event.

Reduce alarm noise

These best practices can help you reduce the noise that an issue alert can produce, but do not apply to indicator alerts.

Seeing the same Alerts: If you repeatedly see the same alerts you’ve seen before, try filtering your issue alerts to issues created in the past few days, using the issue is older or newer than… The filter.

Transient Alerts: To filter out Transient issues that occur only a few times in quick succession and do not occur again, use the Issue Has Happened at least {X} times filter in your Issue alerts.

Limit to Latest Release: Use The Event is from The latest Release filter to apply your issue alert only to The latest release.

Use the “For Review” list: New issues and unresolved issues are usually the ones you want to know about, but they make a lot of noise. The “For Review” TAB in the Sentry Issues list shows these issues, so you can use email and integration to raise higher urgency alerts while ensuring that these lower urgency issues don’t go unnoticed. We recommend checking the “For Review” list once a day. This list shows:

  • A new Issue
  • Regression (issue"Resolved" - > "Unresolved"Change status)
  • Satisfies the ignore conditionissue(issueState fromIgnored -> Unresolved)
Has neglected Issue

You can ignore an issue to reduce noise, but when an alert condition is met, the ignored issue does not trigger an alert; Instead, they become unresolved and appear in the “For Review” list. Therefore, if you are concerned about missing these issues, create problem alerts using An Issue Changes State from Ignore to Unresolved trigger.

routing

Issue owners: Using Issue owners lets Sentry automatically send alerts to the right people and reduces the configuration burden. You can configure ownership rules in [Project] > Settings > Issue Owners ([Project] > Settings > Issue Owners). When there is no matching owner, the alert is sent to all project members by default. If this is too broad and you want a specific owner as backup, end your ownership rule with a rule like *:

.

Delivery methods for different priorities: Different sending modes are used to distinguish alarms with different priorities. For example, you can route from highest priority to lowest priority like this:

  • High priority: pages (PagerDutyOpsGenie)
  • Medium priority: Chat application (Slack)
  • Low priority:Email

The “For Review” TAB in the list of issues is where you can check For the lowest-priority issues without receiving any alerts.

Build Integration: If you want to route alert notifications to a solution that Sentry does not already integrate out of the box, you can use the Integration Platform. It will be available in the Alert Actions menu when the integration is created. You might want to use your integration for:

  • Send alerts to integrations that are not supported natively
  • Aggregate alerts from different monitoring systems
  • inwebhookWrite custom rules in the handler to route alerts more intelligently

notice

Sentry sends you notifications about workflow activity, release deployment and quota usage, and weekly reports. These notices let you know:

  • Workflow (Workflow) : Involves user operations andissueActivities for state changes. This includesissueActivities such as resolution, distribution, comment and regression.
  • Deployment (Deploy) : When your committed version is deployed.
  • The quota (Quota) : Near quota, over quota and peak protection.
  • Weekly Report (Weekly Reports) : You organized itSentryActivity summary.

You can manage these Notifications in User Settings > Notifications.

Workflow notification

Sentry sends workflow notifications to let you know about issue status changes. Workflows are related to actions that help you manage problems, such as changing the status of an issue or commenting on it. By default, Sentry sends these notifications via E-mail to members that subscribe to the problem (see below for how to determine subscription). Sending workflow notifications:

  • The Issue Resolved: When new is found in your codeissueWhen, it is inUnresolvedState. When project team members pass insentry.ioTo manually change its status or submit a fix or resolve due to the project’s automatic resolution feature (if configured)issueWhen,issueThe status changes to resolved.
  • Regression (Regressions): whenissueThe state of the from"Resolved"Go back to"Unresolved", regression will occur. An email will be sent to all project team members.
  • Comments (Comments): When team members are inissueDetails page"The Activity"TAB when adding a new comment.
  • Assignment: When a problem is assigned or not assigned.
  • User Feedback: when aissueWhen there is new user feedback.
  • Event Processing Problems: When you send toSentryError event handling when there is a problem.

When you subscribe to an issue, you receive workflow notifications, and you subscribe to issues by:

  • Click on theissueSubscription bell (subscribe bell) icon
  • Participate in andissueRelated submissions
  • rightissueLeave a comment or bookmark
  • inissueReferences to you or your team
  • You or your team are assigned to thisissue

There may be some overlap between these notifications and the alerts configured for the project.

Deployment notification

Sentry sends deployment notifications to users who have committed the deployed version. Learn more in the deployment documentation.

  • Docs. Sentry. IO/product/rel…

Notice the quotas

Sentry sends quota notifications to all owners of the organization in the following cases:

  • 80% of the organization’s error, transaction, and attachment volume is exhausted.
  • An error or transaction exceeds the organization’s quota, which includes on-demand capacity

You cannot change or disable these notifications. Learn more in the complete quota documentation.

  • Docs. Sentry. IO/product/acc…

Weekly report

Sentry sends weekly reports via email every Monday. The report contains a summary of your organization’s Sentry activities during the last week.

Personal Notification Settings

You can adjust your personal workflow and deploy notifications as well as your personal Issue alert Settings in your account Settings. Manage your Notifications by navigating to User Settings > Notifications. You cannot configure quota notification.

The alarm

This setting does not affect alerts configured to be explicitly sent to your email.

In notifications, you can turn issue alert notifications on and off globally.

You can also fine-tune the alert notifications for each project by selecting “Default,” “On,” or “Off.” If you select “Default”, the project’s Settings will be the same as your global Settings.

delivery

You can decide where to receive personal alert notifications by selecting from the following options:

  • Sent to theEmail
  • Sent to theSlack
  • Sent to theEmailSlack

Slack is only available as a delivery method if your organization has integration installed and your Slack identity is linked to your Sentry account.

  • Docs. Sentry. IO/product/int…

workflow

The global Settings for workflow notifications are:

  • Always (Always)
  • Only On Issues I Subscribe To
  • Never (Never)

You can fine-tune your workflow notifications for each project by selecting one of the above three options or “Default.” If you select “Default”, the project’s Settings will be the same as your global Settings.

delivery

You can decide where to receive personal workflow notifications by selecting from the following options:

  • Sent to theEmail
  • Sent to theSlack
  • Sent to theEmailSlack

Slack is only available as a delivery method if your organization has installed integration and your Slack identity is linked to your Sentry account.

unsubscribe

To exit workflow notification for a particular issue, click the subscribe bell icon at the top of the issue page.

Email routing

Email routing controls the email address to which each item notification is sent. These notifications default to the email address you provided when setting up your Sentry account. This setting allows you to route E-mail to alternate E-mail addresses on a per-item basis.

Weekly report

The report contains a summary of your organization’s Sentry activities during the last week. You can fine-tune your weekly reports by turning them on and off for each organization.

The deployment of

The global Settings for deployment notifications are:

  • On
  • Only On Deploys With My Commits(Only on the deployment I submitted)
  • Off

You can fine-tune deployment notifications for each organization by selecting one of the three options above or “Default.” If you select “Default,” the organization’s Settings will be the same as your global Settings.

delivery

You can decide where to receive personal workflow notifications by selecting from the following options:

  • Sent to theEmail
  • Sent to theSlack
  • Sent to theEmailSlack

Slack is only available as a delivery method if your organization has installed integration and your Slack identity is linked to your Sentry account.

My activities

Use toggle switches to control whether you receive notifications about:

  • You are usingsentry.ioAt the time of the action
  • You have resolved the unclaimedissueAny changes to