diff --git a/docs/cli/configuration.mdx b/docs/cli/configuration.mdx index 20b49ec389ffc..d2dac2fa0aa4b 100644 --- a/docs/cli/configuration.mdx +++ b/docs/cli/configuration.mdx @@ -27,7 +27,7 @@ You can manually create an [Organization Token](https://sentry.io/orgredirect/or You can also sign in to your Sentry account (if you're not already) and create an Auth Token directly from this page. -Some CLI functionality, such as [Crons Monitoring](/product/crons/getting-started/cli/), is dependent on [Data Source Name (DSN)](/concepts/key-terms/dsn-explainer/) authentication. +Some CLI functionality, such as [Crons Monitoring](/product/monitors/crons/getting-started/cli/), is dependent on [Data Source Name (DSN)](/concepts/key-terms/dsn-explainer/) authentication. You can create an Auth Token from this page in one of the following three ways: diff --git a/docs/cli/crons.mdx b/docs/cli/crons.mdx index eba6b12d8c246..761f58b0d8c4a 100644 --- a/docs/cli/crons.mdx +++ b/docs/cli/crons.mdx @@ -84,7 +84,7 @@ sentry-cli monitors run -s "0 * * * *" --check-in-margin 10 --max-runtime 5 --ti ### Specifying Monitor Environments (Optional) -If your cron monitor runs in multiple environments you can use the `-e` flag to specify which [Monitor Environment](/product/crons/job-monitoring/#multiple-environments) to send check-ins to. +If your cron monitor runs in multiple environments you can use the `-e` flag to specify which [Monitor Environment](/product/monitors/crons/job-monitoring/#multiple-environments) to send check-ins to. ```bash {tabTitle: Node.JS} sentry-cli monitors run -e dev my-monitor-slug -- node path/to/file.js diff --git a/docs/platforms/dotnet/common/crons/hangfire/index.mdx b/docs/platforms/dotnet/common/crons/hangfire/index.mdx index 32b874fe98a31..b29ca00e8e3fe 100644 --- a/docs/platforms/dotnet/common/crons/hangfire/index.mdx +++ b/docs/platforms/dotnet/common/crons/hangfire/index.mdx @@ -4,7 +4,7 @@ description: "Learn more about how to monitor your Hangfire jobs." sidebar_order: 5001 --- -The .NET SDK provides an integration with [Hangfire](https://www.hangfire.io/) to monitor your jobs by automatically [creating check-ins for them](/product/crons/job-monitoring/). The SDK relies on job filters that are set up when you call `UseSentry`. For example: +The .NET SDK provides an integration with [Hangfire](https://www.hangfire.io/) to monitor your jobs by automatically [creating check-ins for them](/product/monitors/crons/job-monitoring/). The SDK relies on job filters that are set up when you call `UseSentry`. For example: ```csharp using Hangfire; diff --git a/docs/platforms/java/common/crons/troubleshooting.mdx b/docs/platforms/java/common/crons/troubleshooting.mdx index ba79cba0ba2d8..f5e6ef10c7667 100644 --- a/docs/platforms/java/common/crons/troubleshooting.mdx +++ b/docs/platforms/java/common/crons/troubleshooting.mdx @@ -6,7 +6,7 @@ sidebar_order: 9000 -Attachments aren't supported by our Java SDK yet. For now, you can use the [check-in attachments API](/product/crons/getting-started/http/#check-in-attachment-optional). +Attachments aren't supported by our Java SDK yet. For now, you can use the [check-in attachments API](/product/monitors/crons/getting-started/http/#check-in-attachment-optional). diff --git a/docs/platforms/javascript/common/configuration/integrations/denocron.mdx b/docs/platforms/javascript/common/configuration/integrations/denocron.mdx index 74d7875ac43c3..6b6050db80afe 100644 --- a/docs/platforms/javascript/common/configuration/integrations/denocron.mdx +++ b/docs/platforms/javascript/common/configuration/integrations/denocron.mdx @@ -13,7 +13,7 @@ This integration only works in the Deno runtime. _Import name: `Sentry.denoCronIntegration`_ -[Sentry Crons](/product/crons/) allows you to monitor the uptime and performance of any scheduled, recurring job in your application. +[Sentry Crons](/product/monitors/crons/) allows you to monitor the uptime and performance of any scheduled, recurring job in your application. The DenoCron integration sets up automatic monitoring for your cron jobs created by [`Deno.cron`](https://docs.deno.com/deploy/kv/manual/cron). It captures check-ins and sends them to Sentry. diff --git a/docs/platforms/javascript/guides/nextjs/manual-setup.mdx b/docs/platforms/javascript/guides/nextjs/manual-setup.mdx index 092f6597dacb2..440e0071cc507 100644 --- a/docs/platforms/javascript/guides/nextjs/manual-setup.mdx +++ b/docs/platforms/javascript/guides/nextjs/manual-setup.mdx @@ -492,7 +492,7 @@ module.exports = withSentryConfig(nextConfig, { ## Step 6: Instrument Vercel Cron Jobs (Optional) -You can automatically create [Cron Monitors](/product/crons/) in Sentry if you have configured [Vercel cron jobs](https://vercel.com/docs/cron-jobs). +You can automatically create [Cron Monitors](/product/monitors/crons/) in Sentry if you have configured [Vercel cron jobs](https://vercel.com/docs/cron-jobs). Update `withSentryConfig` in your `next.config.(js|mjs)` file with the following option: diff --git a/docs/product/alerts/alert-types.mdx b/docs/product/alerts/alert-types.mdx deleted file mode 100644 index 0cfe5ea1f507c..0000000000000 --- a/docs/product/alerts/alert-types.mdx +++ /dev/null @@ -1,139 +0,0 @@ ---- -title: Alert Types -sidebar_order: 10 -description: >- - Learn about the three types of alerts Sentry provides: issue alerts, metric - alerts, and uptime monitoring alerts. -og_image: /og-images/product-alerts-alert-types.png ---- - -You can create three types of alerts: - -1. **Issue alerts**: Trigger when an issue matches a specific criteria. -2. **Metric alerts**: Trigger when macro-level metrics cross specific thresholds. -3. **Uptime alerts**: Trigger when an HTTP request doesn't return a successful response. - -## Issue Alerts - -Issue alerts trigger whenever a new event is received for any issue in a project matching the specified criteria. These criteria might be, for example, a resolved issue re-appearing or an issue affecting many users. - -In the “Alert Rules” tab, these alerts are identified by the issues icon, and by default, they are displayed at the bottom of your list of alerts. (If you have several metric alerts, this may push your issue alerts off the first page of the list.) - -![Issue alert rules at the bottom of the list of alerts.](./img/issue-alert-rules.png) - -In issue alerts, Sentry evaluates the configured alert conditions each time it receives a new event. Alert conditions have three parts: - -1. [Triggers](/product/alerts/create-alerts/issue-alert-config/#when-conditions-triggers) specify what type of activity you'd like monitored, or **When** an alert should be triggered. -2. [Filters](/product/alerts/create-alerts/issue-alert-config/#if-conditions-filters) help control noise by triggering an alert only **If** the issue matches the specified criteria. -3. **Then**, [Actions](/product/alerts/create-alerts/issue-alert-config/#then-conditions-actions) specify what should happen when the trigger conditions are met and the filters match. - -### Alert Details - -The **Alert Details** page shows you the number of times an issue alert rule was triggered over time, grouped in one hour buckets. Clicking on the alert rule name in the "Alert Rules" tab, or on the notification you receive will take you to this page. The page also includes the alert rule conditions, the current status of the alert (Warning, Critical, or Resolved), and alert details such as when it was created, when it was last modified, and the team that owns the alert. - -![Alert details illustrates a graph showing the alerts triggered over time.](./img/issue-alert-status-page-example.png) - -The **Alert Details** page also includes a list of issues that triggered the alert. You can click on any of the issues in the list to go to that issue's details page for more information. - -## Metric Alerts - -Metric alerts tell you when a [metric](/product/insights/overview/metrics/) crosses a threshold set by you, like a spike in the number of errors in a project, or a change in a performance metric, such as [transaction duration](/product/insights/overview/metrics/#latency), [Apdex](/product/insights/overview/metrics/#apdex), [failure rate](/product/insights/overview/metrics/#failure-rate), or [throughput](/product/insights/overview/metrics/#throughput-total-tpm-tps). You can use [dynamic alerts](/product/alerts/create-alerts/metric-alert-config/#dynamic-alerts) to let Sentry define the threshold for you. - -Metric alerts monitor macro-level metrics for both error and transaction events. A metric takes a set of events and computes an aggregate value using a function, such as `count()` or `avg()`, applied to the event properties over a period of time. When you create a metric alert, you can filter events by attributes and tags, which is particularly useful for aggregating across events that aren't grouped into single issues. Sentry allows a maximum of 1000 metric alerts for an organization. - - - -Metric alerts may include [archived issues](/product/issues/states-triage/#archive) if events from those issues match the filters of your metric alert rule. Events from archived and resolved issues can be filtered out by using the `is:unresolved` filter in your metric alert rule. This filter is added by default when creating a new metric alert, but you may need to manually add it to older metric alerts if you want them to exclude archived issues. - - - -These alerts use _Critical_ and _Warning_ triggers to measure severity. An alert’s current status is the highest severity trigger that is active, which can be one of three values: Warning, Critical, or Resolved. Sentry notifies you whenever an alert's status changes. - -When you create an alert, all the displayed alert types (except “Issues”) may be used to create a metric alert. You can create metric alerts for Errors, Sessions (Crash Rate Alerts), and Performance: - -### Errors - -Error alerts are useful for monitoring the overall level of errors in your project, errors occurring in specific parts of your app, or errors affecting your users. - -- **Number of Errors:** - Alerts when the number of errors in a project matching your filters crosses the threshold you set. - -- **Users Experiencing Errors:** - Alerts when the number of users affected by errors in your project crosses the threshold you set. - -### Sessions (Crash Rate Alerts) - -Crash rate alerts can give you a better picture of the health of your app on a per project basis or in a specific release. They trigger when the crash-free percentage for either [sessions or users](/product/releases/health/#active-sessionsusers) falls below a specific threshold. This could happen because of a spike in the number of session or user [crashes](/product/releases/health/#crashes). - -- **Crash Free Session Rate:** - Alerts when the number of crashed sessions exceeds the threshold you set. A session begins when a user starts the application and ends when it’s closed or sent to the background. A crash is when a session ends due to an error. - -- **Crash Free User Rate:** - Alerts when the overall user experience dips below the threshold you set. Crash Free Users represents the percentage of individual users who haven’t experienced a crash. - -### Performance - -Application performance alerts can help you pinpoint and identify specific problems that may be causing a suboptimal experience for your users. - -- **Throughput:** - Alerts when throughput (the total number of transactions in a project) reaches a threshold set by you within a specified period of time. - -- **Transaction Duration:** - Alerts when transaction durations meet certain conditions. - -**TIP:** The conditions can be customized with flexible aggregates like percentiles, averages, and min/max. - -- **Apdex:** - Alerts on the Apdex score (the ratio of satisfactory, tolerable, and frustrated requests in a specific transaction or endpoint). Apdex is a metric used to track and measure user satisfaction based on your application response times. - -- **Failure Rate:** - Alerts on failure rate (the percentage of unsuccessful transactions). Sentry treats transactions with a status other than “ok,” “canceled,” and “unknown” as failures. - -- **Largest Contentful Display:** - Alerts when the Largest Contentful Paint (LCP), which measures loading performance, is loading slower than expected. LCP marks the point when the largest image or text block is visible within the viewport. - -**TIP:** A fast LCP helps reassure the user that the page is useful. We recommend an LCP of less than 2.5 seconds. - -- **First Input Delay:** - Alerts when First Input Delay (FID), which measures the response time when a user tries to interact with the viewport, is longer than expected. - -**TIP:** A low FID helps ensure that a page is useful. We recommend a FID of less than 100 milliseconds. - -- **Cumulative Layout Shift:** - Alerts when cumulative Layout Shift (CLS), which measures visual stability by quantifying unexpected layout shifts that occur during the entire lifespan of the page, increases. - -**TIP:** A CLS of less than 0.1 translates to a good user experience, while anything greater than 0.25 is poor. - -- **Custom Metric:** - Alerts on metrics which are not listed above, such as first paint (FP), first contentful paint (FCP) and time to first byte (TTFB). - -### Alert Details - -The **Alert Details** page shows you the history of a metric alert rule for the last 24 hours by default, though can modify the time period using the "Display" dropdown. When an alert is triggered, clicking the notification you receive takes you to this page, which displays the period when the alert was active. The page also includes details such as the alert rule conditions, the current status of the alert, and a summary of how much time the alert spent in each state (Critical, Warning, or Resolved). - -![Alert details illustrates a graph showing the performance of a transaction over time.](./img/alert-details-example.png) - -The **Alert Details** page also includes a list of suspect issues or transactions related to the metric, to help pinpoint the root problem more quickly. You can see what might have caused the alert to be triggered, and then open the metric in **[Discover](/product/explore/discover-queries)** to find more information. - -## Uptime Alerts - -Uptime alerts trigger whenever an uptime check request fails to meet our [uptime check criteria](/product/uptime-monitoring/#uptime-check-criteria). You'll be able to see the latest uptime check request status ("Up" or "Down") in the “Alert Rules” tab. - -### Alert Details - -The **Alert Details** page provides a timeline of uptime check events associated with the alert. This timeline allows you to track when and where failures occurred. Selecting a section of the timeline automatically updates the date range filter, enabling you to browse historical uptime check data. - -The **Alert Details** page also includes a list of [uptime issues](/product/issues/issue-details/uptime-issues) that were created by the alert when uptime failures are detected. Clicking on any of the issues will take you to a page with additional information that may help you debug that issue. - -## User Feedback Alerts - -You can enable alerts for the [User Feedback Widget](/product/user-feedback/#user-feedback-widget) on the [issue alerts](https://sentry.io/orgredirect/organizations/:orgslug/alerts/new/issue/) page by following the steps below: - -1. Create a [New Alert Rule](https://sentry.io/orgredirect/organizations/:orgslug/alerts/new/issue/) in Sentry. -2. Scroll to the "Set conditions" section and set the "IF" filter to `The issue's category is equal to… "Feedback"`. -3. Choose which actions to perform in the “THEN” filter. -4. Add an alert name and owner. - -![User Feedback Alert Configuration.](../user-feedback/img/user-feedback-alert-configuration.png) - -To get alerts when [crash-report feedback](/product/user-feedback/#crash-report-modal) comes in, make sure to turn on "Enable Crash Report Notifications" in Settings > Projects > [Project Name] > User Feedback. diff --git a/docs/product/alerts/best-practices.mdx b/docs/product/alerts/best-practices.mdx index a565b236f9cf4..e0517363d76f9 100644 --- a/docs/product/alerts/best-practices.mdx +++ b/docs/product/alerts/best-practices.mdx @@ -7,9 +7,7 @@ description: "Learn best practices for creating alerts." Alerts should notify you when there's an important problem with your application. But they shouldn't be too noisy, because that can lead to alert fatigue. The following best practices will help you create relevant alerts that notify the right people — that is, the people equipped to fix the problem. -There are two types of alerts: [issue alerts](/product/alerts/alert-types/#issue-alerts) and [metric alerts](/product/alerts/alert-types/#metric-alerts). Most of our alerting best practices are specific to issue alerts, however, the [alert conditions best practices](#alert-conditions-best-practices) apply to both issue and metric alerts. - -## Issue Alerts Best Practices +## Best Practices An issue alert is triggered when an individual issue meets some criteria. These criteria (or "triggers") can be based on state-changes or frequency. The best practices that follow cover alerts based on state and frequency changes, as well as reducing noise, and effective routing. diff --git a/docs/product/alerts/create-alerts/img/alert-digest.png b/docs/product/alerts/create-alerts/img/alert-digest.png deleted file mode 100644 index 11f3e057a2fe8..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/alert-digest.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/alert-list-row-menu.png b/docs/product/alerts/create-alerts/img/alert-list-row-menu.png deleted file mode 100644 index d86bc0de33fd4..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/alert-list-row-menu.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/alerts-advanced-filters.png b/docs/product/alerts/create-alerts/img/alerts-advanced-filters.png deleted file mode 100644 index e0281ee598ed9..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/alerts-advanced-filters.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/alerts-notifications-discord.png b/docs/product/alerts/create-alerts/img/alerts-notifications-discord.png deleted file mode 100644 index e191a34a8a8a3..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/alerts-notifications-discord.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/alerts_notifications_15.png b/docs/product/alerts/create-alerts/img/alerts_notifications_15.png deleted file mode 100644 index ae2a6ef2e0dbf..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/alerts_notifications_15.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/create-new-alert-rule.png b/docs/product/alerts/create-alerts/img/create-new-alert-rule.png deleted file mode 100644 index c93c38a05ffa5..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/create-new-alert-rule.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/dynamic-threshold.png b/docs/product/alerts/create-alerts/img/dynamic-threshold.png deleted file mode 100644 index 2c72dc7bd4985..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/dynamic-threshold.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/issue-change-alert.png b/docs/product/alerts/create-alerts/img/issue-change-alert.png deleted file mode 100644 index fd4f4d34081aa..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/issue-change-alert.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/percent-change.png b/docs/product/alerts/create-alerts/img/percent-change.png deleted file mode 100644 index 7afff6aecae15..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/percent-change.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/suggested_assignee_all_members.png b/docs/product/alerts/create-alerts/img/suggested_assignee_all_members.png deleted file mode 100644 index 2e21ce270eccf..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/suggested_assignee_all_members.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/uptime-alert-expected-check-request.png b/docs/product/alerts/create-alerts/img/uptime-alert-expected-check-request.png deleted file mode 100644 index 2605d050c4401..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/uptime-alert-expected-check-request.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/img/uptime-alert-request-config.png b/docs/product/alerts/create-alerts/img/uptime-alert-request-config.png deleted file mode 100644 index 286f6886bd11b..0000000000000 Binary files a/docs/product/alerts/create-alerts/img/uptime-alert-request-config.png and /dev/null differ diff --git a/docs/product/alerts/create-alerts/index.mdx b/docs/product/alerts/create-alerts/index.mdx deleted file mode 100644 index b8bd954e96844..0000000000000 --- a/docs/product/alerts/create-alerts/index.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Create Alerts -sidebar_order: 20 -description: >- - Learn how to create alerts that keep you informed about errors and performance - issues in your application. -og_image: /og-images/product-alerts-create-alerts.png ---- - - - -The minimum role required to create alerts is member. Sentry users with manager or owner permissions can change the minimum role requirement in **Settings > General Settings > Let Members Create and Edit Alerts**. - - - -To create alerts: - -1. Navigate to **Alerts** and click "Create Alert Rule". -1. Choose what you want to be alerted about. Selecting “Issues” creates an [issue alert](/product/alerts/alert-types/#issue-alerts), selecting “Uptime Monitor” creates an [uptime alert](/product/alerts/alert-types/#uptime-alerts), while selecting any other option creates a [metric alert](/product/alerts/alert-types/#metric-alerts). - ![Choice between alerts about Errors, Sessions, Performance, or a Custom Metric](./img/create-new-alert-rule.png) - -1. Click "Set Conditions". -1. On the alert configuration page, set the conditions of the alert: - - [Issue Alert Configuration](/product/alerts/create-alerts/issue-alert-config/) - - [Metric Alert Configuration](/product/alerts/create-alerts/metric-alert-config/) - - [Uptime Alert Configuration](/product/alerts/create-alerts/uptime-alert-config/) - -## Duplicate Alerts - -You can also create an alert by duplicating an existing issue or metric alert rule. To do so, navigate to **Alerts** and click "Duplicate" in the context menu (under "Actions") on the row with the alert rule you want to copy: - -![Expanded alert list row context menu](./img/alert-list-row-menu.png) - -## Alert Limits - -[Issue alerts](/product/alerts/alert-types/#issue-alerts) are limited to 100 alerts with "slow" conditions, and 500 alerts with "fast" conditions. -A "slow" condition is a [change](/product/alerts/create-alerts/issue-alert-config/#change-alerts) or [percent based](/product/alerts/create-alerts/issue-alert-config/#percent-based-alerts) alert. These take more processing time than the "fast" conditions, which are related to issue state changes. [Uptime alerts](/product/alerts/alert-types/#uptime-alerts) are limited to 100 alerts. diff --git a/docs/product/alerts/create-alerts/issue-alert-config.mdx b/docs/product/alerts/create-alerts/issue-alert-config.mdx deleted file mode 100644 index b336a4deec5bc..0000000000000 --- a/docs/product/alerts/create-alerts/issue-alert-config.mdx +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: Issue Alert Configuration -sidebar_order: 10 -description: Learn more about the options for configuring an issue alert. -og_image: /og-images/product-alerts-create-alerts-issue-alert-config.png ---- - -Sentry provides several configuration options to create an issue alert based on your organization's needs. - -## Environment - -Specify which environment(s) will use this particular alert rule. This control filters on the `environment` tag in your events. This filter is helpful because the urgency and workflows you apply to production alerts might differ from those you apply to alerts originating from your QA environment, for example. - -The “Environment” dropdown list here has the same environments that are available for the selected project in the common “Environment” filter dropdown (this does not include hidden environments). Selecting "All Environments" is equivalent to having no environment filter. - -## Project - -Specify which project will use this particular alert rule. The created alert rule will only process events from this project. - -## "When" Conditions: Triggers - -"When" conditions, or triggers, specify what type of activity you'd like monitored for the issue: - -- New issue is created -- Changes state from `resolved` to `unresolved` -- Changes state from `archived` to `escalating` -- The number of events in an issue is more than a certain number or has a higher [percent change](#change-alerts) in an interval -- The number of unique users is more than a certain number or has a higher [percent change](#change-alerts) in an interval -- An issue affects more than [\{X\} percent of sessions in \{time\}](#percent-based-alerts) -- A new issue is marked as [high priority](/product/issues/issue-priority/) -- An existing issue is marked as [high priority](/product/issues/issue-priority/) - -Triggers are optional. If you don’t select a trigger, the "When" conditions are considered met by default. That is, _all_ events will meet this condition. - -Learn more about issue states in [Issue States & Triage](/product/issues/states-triage/). - -### Change Alerts - - - -When you select the number of events or users affected by an issue as a trigger, you have the option to set that trigger based on percent change. Percent change triggers are useful for alerting you when the number of errors in an issue or the number of unique users affected is significantly different from normal. - -For example, an alert can be triggered when an issue is affecting 10% more unique users in an hour compared to a week ago. Another example would be when the number of events in an issue is 40% higher this week than it was 30 days ago. - -![The conditions that can be set to alert on an issue.](./img/issue-change-alert.png) - -### Percent-Based Alerts - -You can set a trigger for when an issue affects more than \{X\} percent of [sessions](/product/releases/health/#session) in \{time\}. - -_Percent of sessions affected_ is an approximation that's calculated by taking the number of sessions in the last hour and scaling it to the alerting window appropriately. For example, if the alert is configured to look at the last five minutes, the number of sessions is approximated by taking the number of sessions in the last hour and dividing it by 12. - -Percent-based alerts will only trigger if the number of sessions in the last hour exceeds 50. - -## "If" Conditions: Filters - -Sentry checks "if conditions", or filters, after “When” conditions are met, and these help control noise by filtering out issues that don’t match your specified criteria. You can filter on issue or event properties. If an event filter is specified, it checks only the event that triggered the alert, such as: - -- The issue is older or newer than a certain duration. -- The issue has happened at least \{X\} times. -- The issue is assigned to \{no one/a team/a member\}. -- The event is from the latest release. -- The event's \{attribute\} \{matches\} \{value\}. Match types: equals, does not equal, starts with, ends with, contains, does not contain, is set, is not set, is in, or is not in. -- The event's \{tag\} \{matches\} \{value\}. Match types: equals, does not equal, starts with, ends with, contains, does not contain, is set, is not set, is in, or is not in. -- The event's level \{matches\} \{level\}. Match types: equal to, less than or equal to, or greater than or equal to. - -Learn more about and tags and [event attributes](/concepts/search/searchable-properties/#event-properties). - -## “Then” Conditions: Actions - -"Then conditions", or actions, specify what should happen when trigger and filter conditions are met: - -- Send a notification to either [Suggested Assignees](#suggested_assignees), a team, or a member. -- Send a notification to an integration, which can include these options, depending on which integrations you have installed: - - Send a [Slack](/organization/integrations/notification-incidents/slack/) notification - - Send a [Discord](/organization/integrations/notification-incidents/discord/) notification - - Send a [PagerDuty](/organization/integrations/notification-incidents/pagerduty/) notification - - Send a [Microsoft Teams](/organization/integrations/notification-incidents/msteams/) notification - - Send a notification to all legacy integrations - - Send a notification using an [integration](/organization/integrations/) built on the [integration platform](/organization/integrations/integration-platform/#alerts) -- Create an issue for an [integration](/organization/integrations/), which includes: - - [Jira](/organization/integrations/issue-tracking/jira/) - - [Azure DevOps](/organization/integrations/source-code-mgmt/azure-devops) - -Learn more about [routing alerts with integrations](/product/alerts/create-alerts/routing-alerts/). - -### Suggested Assignees - -Suggested Assignees include people or teams currently assigned the issue, issue owners defined in [ownership rules](/product/issues/ownership-rules/), and anyone who has been identified as author of a [suspect commit](/product/issues/suspect-commits/). When an alert is triggered, they can choose to be notified via email or Slack (depending on their [notification settings](/product/alerts/notifications/notification-settings/)). - -If no suggested assignees are found, the notification will be sent to the teams or members specified in the fallback notification setting, as shown below: - -![Suggested Assignees with notify all project members selected.](./img/suggested_assignee_all_members.png) - -The following members will be notified based on the option selected and their notification settings: - -- **All Project Members:** Every team member who has access to the project will be notified. This could potentially notify a large number of people. If two teams have access to the project, every member of both teams will be notified. -- **Recently Active Members:** The 20 most recently logged-in members, who have access to the project. -- **Nobody:** No one will be notified. - -### Team Slack Notifications - -Teams can configure a Slack channel to receive alert notifications. This can be done by typing `/sentry link team` in the desired Slack channel. To view a team's associated Slack channel in [sentry.io](https://sentry.io), navigate to **Settings > Teams > [Team] > Notifications**. - -### Notification Tests - -Notification tests allow you to test if your integrations are working properly. Sending a test notification creates a dummy event and sends a notification to all of the selected integrations. - -## Action Interval (Rate Limit) - -The action interval, or rate limit, controls how often the alert rule can be triggered for a particular issue. If alert conditions match an issue, Sentry executes the actions only if they haven't already been executed for that issue within the rate limit period. For example, if an issue meets alert conditions multiple times in a one-minute period, but your frequency threshold is one minute, you’ll only be alerted once. - -The available intervals are: - -- Minutes: 5, 10, 30, 60 -- Hours: 3, 12, 24 -- Days: 7, 30 - -## Alert Preview - -The preview displays a list of issues that would have triggered the alert and the last time they would have triggered it. - -Rules with any of following can't be previewed: - -- The issue is assigned to \{no one/a team/a member\}. -- The event is from the latest release. -- An issue affects more than [\{X\} percent of sessions in \{time\}](#percent-based-alerts) -- No ["When" conditions](#when-conditions-triggers) -- Both [issue frequency](#change-alerts) conditions and [event filters](#if-conditions-filters) (filters that start with "The event") - -## Alert Name - -Give your alert a descriptive name, such as the team affected and the topic of the alert. For example, "Frontend Latency", "Backend Failure Rate", or "Billing Apdex". - -## Team - -You can choose a team to associate with an alert so that members of that team can edit the alert. Note that you can only make this association if you are a member of the team. If no team is selected, anyone can edit the alert. - -## Project-Level Alert Settings - -In **[Project] > Settings > Alerts**, you can configure alert email subject templates and digest settings. Sentry users with owner, manager, or admin permissions and above can change these default notification settings. - -### Digests - -The digests feature only works for issue alert emails (not notifications sent through integrations), and unlike the [action interval](#action-interval-rate-limit), 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. - -The minimum interval sets how soon another digest can be sent after the previous one. Each new alert resets the timer, delaying the next digest until the maximum interval is reached. If there hasn’t been a recent digest, the first alert is delivered immediately. - -![A sliding adjustment scale for the frequency of alert emails.](./img/alert-digest.png) diff --git a/docs/product/alerts/create-alerts/metric-alert-config.mdx b/docs/product/alerts/create-alerts/metric-alert-config.mdx deleted file mode 100644 index bb07bbf14c1e0..0000000000000 --- a/docs/product/alerts/create-alerts/metric-alert-config.mdx +++ /dev/null @@ -1,184 +0,0 @@ ---- -title: Metric Alert Configuration -sidebar_order: 20 -description: Learn more about the options for configuring a metric alert. -og_image: /og-images/product-alerts-create-alerts-metric-alert-config.png ---- - -Sentry provides several configuration options to create a metric alert based on your organization's needs. - -## Metric (Type + Function + Time Interval) - -To create a metric alert you first need to choose a metric type. For some alert types the function is built into the alert and for others you can choose functions and parameters to apply to it. For example, if you select “Users Experiencing Errors”, that translates to the function, `count_unique(user.id)`. Since editing this function would change the nature of the alert, it is not editable and thus hidden. On the other hand, if you select “Largest Contentful Paint” the measurement used is `measurement.lcp`, you also need to choose a function, e.g. `p75()`, for a combined metric function of `p75(measurement.lcp)`. - - -When creating new metric alerts, the `is:unresolved` filter is added by default. This filter excludes events from archived and resolved issues. If you want your metric alerts to include archived issues, you can manually remove `is:unresolved` from your [filters](#filters). - - -### Metrics Types for Alerting - -#### Errors - -- Number of Errors -- Users Experiencing Errors - -#### Sessions - -- Crash Free Session Rate -- Crash Free User Rate - -#### Performance - -- Throughput -- Transaction Duration -- Apdex -- Failure Rate -- Largest Contentful Paint -- First Input Delay -- Cumulative Layout Shift -- Custom Measurement - -#### Metrics -- Custom Metric - -### Functions for Metric Types - -- `count()` -- `count_unique(...)` -- `avg(...)` -- `percentile(...)` -- `failure_rate()` -- `apdex(...)` -- `count()` -- `p50()` -- `p75()` -- `p95()` -- `p99()` -- `p100()` - -### Time Interval - -Choose the time period over which to evaluate your metric. Your choices range between one minute and one day. Sentry evaluates the specified window each minute. For example, if you specify an 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 -- ... - -## Filters - -The following set of filters translates into a [Discover query](/product/explore/discover-queries/) that is displayed in the chart at the top of the alert configuration page. - -### Project - -Specify which project will use this particular alert rule. Created alert rule will only process events from this project. - -### Environment - -Specify which environment(s) will use this particular alert rule. This control filters on the `environment` tag in your events. This filter is helpful because the urgency and workflows you apply to production alerts might differ from those you apply to alerts originating from your QA environment, for example. - -The “Environment” dropdown list here has the same environments that are available for the selected project in the common “Environment” filter dropdown (this does not include hidden environments). Selecting "All Environments" is equivalent to having no environment filter. - -### Event Type - -For some metric alerts, you can set the event type that you want to be alerted about in the “Events” dropdown: - -- `event.type:error` OR `event.type:default` -- `event.type:default` -- `event.type:error` - -### Tags & Properties - -Add filters in the provided input to narrow down what you'll be alerted about, such as tags or other event properties. Available properties depend on your alert's type: - -- For **error** events, all error properties are available. See [Searchable Properties](/concepts/search/searchable-properties/events/#searchable-properties) for a full list. -- For **transaction** events, the following basic properties are generally available: `release`, `transaction`, `transaction.status`, `transaction.op`, `http.method`, `http.status_code`, `os.name`, `browser.name`, and `geo.country_code`. - -#### Advanced filters for Transactions - - - -This feature is only available to organizations with a Business or Enterprise plan. - - - -A wider variety of fields or tags are available in addition to the basic properties mentioned above, so you can create more advanced filtering conditions. However, Sentry only starts collecting these metrics after the alert is saved. If such a filter is used, Sentry provides an estimate of the metric for the previous period during the alert's creation. A maximum of 50 alerts with advanced filters is allowed per project on certain legacy plans. - -![Advanced filters for transactions](./img/alerts-advanced-filters.png) - -#### Invalid Filters - -While Sentry won’t allow you to create new alerts with invalid or unavailable properties, any existing alerts with unavailable fields won’t be affected. But if you need to edit or duplicate them, you'll need to remove the unavailable properties. - -## Thresholds - -There are three threshold types: - -- **Static**: A fixed numerical threshold set by you. (For example, if there are 100 errors in a set period of time.) -- **Percent change**: A percent based threshold, such as when there are 10% more errors in a time period compared to a previous period. These are also referred to as [Change Alerts](#change-alerts-percent-change). -- **Anomaly**: A dynamic threshold maintained by Sentry that detects anomalies whenever values fall outside of expected bounds. - -By default, metric alerts use a fixed threshold. - -### Change Alerts (Percent Change) - - - -Change alerts, or alerts that use a percent change threshold, are useful when you want to know if a metric is significantly different from normal. To do this, you’ll need to pick a metric interval (when you're selecting your metric type) and a time against which to compare. One example would be comparing the number of errors in the last hour to the same time period one week ago. If errors are 25% higher in the last hour than they were in the same period a week ago, then an alert will trigger. - -![When the percent change option is selected.](./img/percent-change.png) - -### Anomaly Alerts - - - -Anomaly alerts automatically detect trends outside expected values. They can be especially helpful for spiky or seasonal data that are too noisy for static or percentage based thresholds. Sentry will look at historical data for the given metric and determine if the current data is anomalous. Certain metrics, like Apdex, are currently not supported for anomaly alerts. - -Behind the scenes, anomaly alerts use a combination of two open-source algorithms—[Matrix Profile](https://stumpy.readthedocs.io/en/latest/index.html) and [Prophet Forecasting](https://facebook.github.io/prophet/)—to detect unusual patterns and forecast expected trends. By blending these approaches, Sentry can better distinguish true anomalies from normal fluctuations, reducing false positives and false negatives. - -There are three options for alert responsiveness: low, medium, and high. If you choose low responsiveness, then your alert will fire less frequently but with higher confidence. If you choose high responsiveness, then your alert will fire more frequently with a greater chance of false positives. Our recommendation is to start with medium responsiveness, our default, and adjust the responsiveness based on the results you see. - -Another setting is to set the direction of the alert: above and/or below the expected bounds. This setting can help increase the signal of your alert rule. - -![When the dynamic threshold is selected.](./img/dynamic-threshold.png) - -### Set Threshold to Trigger Alert - -You can set the status of an alert rule when a threshold is met using the labels: - -- Critical -- Warning -- Resolved - -You must set the “Warning” threshold so that it’s triggered before the “Critical” threshold. When Sentry evaluates an alert, the alert’s status is updated to the highest severity trigger that matches. If you don’t set a “Resolved” threshold, the alert automatically resolves when it's no longer breaching the “Critical” or “Warning” conditions. You can also resolve alerts manually. - - - -Note: Anomaly alert thresholds are controlled by Sentry and cannot be manually configured. - - - -### Auto-Resolve - -By default, metric alerts are resolved automatically when the specified metric is no longer breaching the “Critical” or “Warning” conditions. However, you can set a different resolution threshold. For example, suppose a normal level of errors for your app is less than 2000/minute, and you want to be alerted when that exceeds 5000/minute. You might want the alert to resolve only if the level of errors goes back below 2000/minute, not 5000/minute. By setting the "Resolved" threshold this way, if the error level comes back down to only 4000/minute, which you’d consider problematic even though it’s below your alert threshold, the alert won't resolve. - -## Actions - -Actions define how you and your team will be alerted: - -- Send an email to a member or team. If sent to a member, the member's personal project alert opt-out settings are overridden. -- Send a [Slack](/organization/integrations/notification-incidents/slack/) notification. -- Send a [Discord](/organization/integrations/notification-incidents/discord/) notification. -- Trigger a [PagerDuty](/organization/integrations/notification-incidents/pagerduty/) incident. -- Send a [Microsoft Teams](/organization/integrations/notification-incidents/msteams/) notification. -- Send a request using [Sentry integrations](/organization/integrations/integration-platform/#alerts). - -Learn more about [routing alerts with integrations](/product/alerts/create-alerts/routing-alerts/). - -## Rule Name - -Give your alert a descriptive name, such as the team affected and the topic of the alert. For example, "Frontend Latency", "Backend Failure Rate", or "Billing Apdex". This name must be **unique at the organization level**; that is, no other metric alert created in your org can have the same rule name. - -## Team - -You can choose a team to associate with an alert so that members of that team can edit this alert. Note that you can only make this association if you are a member of the team. If no team is selected, anybody can edit the alert. diff --git a/docs/product/alerts/create-alerts/routing-alerts.mdx b/docs/product/alerts/create-alerts/routing-alerts.mdx deleted file mode 100644 index c11c7dc875142..0000000000000 --- a/docs/product/alerts/create-alerts/routing-alerts.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Alert Routing With Integrations -sidebar_order: 40 -description: Learn more about routing alerts using Sentry integrations. -og_image: /og-images/product-alerts-create-alerts-routing-alerts.png ---- - -By customizing [alert](/product/alerts/) rules and integrating the tools you already use, you can receive alerts when, where (and if) you want them, without disruption. Alert notifications can be routed to [Slack](/organization/integrations/notification-incidents/slack/), multiple [supported integrations](/organization/integrations/), and custom integrations through [webhooks](/organization/integrations/integration-platform/webhooks/). When creating alert rules, you can use these integrations to configure who to notify and how. - -## Integrations - -Sentry’s integrations provide you with the option to route your alerts through commonly-used applications like Slack, Discord, PagerDuty, and Microsoft Teams. You can find these integrations in **Settings > Integrations** and [install](https://sentry.io/settings/integrations/) them for your entire organization. - -### Slack Alerts - -A Sentry organization owner, manager, or admin can install and configure the [Slack integration](/organization/integrations/notification-incidents/slack/) in their Sentry account. Once the integration is configured, the following action will be available in issue alert rules: `Send a notification to the \{workspace\} Slack workspace to \{channel\} and show tags \{tags\} in notification`. In metric alerts, your Slack teams will be available in one of the action dropdown lists. - -This alert action allows you to route alert notifications to selected channels (using the `#` prefix), or to a specific user in a direct message (using the `@` prefix) in your Slack workspaces. - -![Slack notification](./img/alerts_notifications_15.png) - -Then, once you receive a Slack notification, you can use the "Resolve", "Archive", or "Assign" buttons to update the issue in [sentry.io](https://sentry.io) directly from Slack. - -### Discord Alerts - -A Sentry organization owner, manager, or admin can install and configure the [Discord integration](/organization/integrations/notification-incidents/discord/) in their Sentry account. Once the integration is configured, the `Send a notification to the \{server\} Discord server with ID: \{channel-id\} and show tags \{tags\} in notification` action will become available in issue alert rules. To be notified about metric alerts via Discord, look for and add your Discord teams in the action dropdown lists. - -This alert action will allow you to route alert notifications to selected channels in your Discord server. - -![Discord notification](./img/alerts-notifications-discord.png) - -You'll be able to "Resolve", "Archive", or "Assign" Sentry issues directly from your Discord notifications. - -### PagerDuty Alerts - -A Sentry organization owner, manager, or admin can install and configure the [PagerDuty integration](/organization/integrations/notification-incidents/pagerduty/) in their Sentry account. Once the integration is configured, the following action will be available in issue alert rules: `Send a notification to PagerDuty account \{account\} and service \{service\}`. In metric alerts, your PagerDuty accounts will be available in one of the action dropdown lists. - -### Microsoft Teams Alerts - -A Sentry organization owner, manager, or admin can install and configure the [Microsoft Teams](/organization/integrations/notification-incidents/msteams/) in their Sentry account. Once the integration is configured, the following action will be available in issue alert rules: `Send a notification to \{team\} Team to \{channel(s)\}`. In metric alerts, your Microsoft teams will be made available in one of the action dropdown lists. - -## Build Your Own Integration - -If you would like to route alert notifications to other solutions that Sentry doesn't have an out-of-the-box integration with, you can use our [integration platform](/organization/integrations/integration-platform/#alerts). The integration platform provides a way for external services to interact with the Sentry SaaS service using the REST API and webhooks. - -Sending alerts to webhooks can also be helpful if you want to do things like aggregate alerts from your 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 show up as a service when you select the `Send a notification via an integration` action during issue alert rule creation. In metric alerts, your integrations are available in one of the action dropdown lists. - -The interactive demo below shows how to set up an integration that can receive Sentry alerts. - - - -## Legacy Integrations - -Legacy integrations (also known as plugins) are extensions of Sentry packaged as Python libraries and configured at the project level. To send an alert to a legacy integration, select the `Send a notification via an integration` or `Send a notification to all legacy integrations` action in an issue alert. You cannot route metric alerts to legacy integrations. diff --git a/docs/product/alerts/create-alerts/uptime-alert-config.mdx b/docs/product/alerts/create-alerts/uptime-alert-config.mdx deleted file mode 100644 index 1f27d94658afc..0000000000000 --- a/docs/product/alerts/create-alerts/uptime-alert-config.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Uptime Alert Configuration -sidebar_order: 30 -description: Learn more about the options for configuring an uptime alert. -og_image: /og-images/product-alerts-create-alerts-uptime-alert-config.png ---- - -Sentry provides several configuration options for creating an uptime alert based on your organization's needs as explained below. - -## 1. Environment - -First, specify which environment this alert rule belongs to. Any [uptime issues](/product/issues/issue-details/uptime-issues/) that will be created from this alert rule will then be set to your specified environment. - -The “Environment” dropdown lists the same environments available in your project, excluding hidden ones. - -## 2. Project - -Specify the project associated with your alert rule. Any [uptime issues](/product/issues/issue-details/uptime-issues/) created will appear under this project. - -## 3. Request Configuration - -![Uptime alert request configuration](./img/uptime-alert-request-config.png) - -Configure how Sentry performs HTTP uptime checks by setting the following options: - -- **Interval**: The time between each uptime check. Options: `1 minute`, `5 minutes`, `10 minutes`, `20 minutes`, `30 minutes`, and `1 hour`. -- **Timeout**: The maximum time Sentry waits for a response before considering the request a failure (up to 30 seconds). -- **URL**: The target URL for the uptime check. -- **Method**: The HTTP method used (`GET`, `POST`, `HEAD`, `PUT`, `DELETE`, `PATCH`, or `OPTIONS`). -- **Headers**: Custom headers included in the request. -- **Body**: The request payload, available for `POST`, `PUT`, and `PATCH` methods. -- **Allow Sampling**: Enables span sampling for requests via the Sentry SDK. See [distributed tracing with uptime](/product/uptime-monitoring/uptime-tracing/) for details. - - - -When adding HTTP headers, be cautious of including sensitive data, such as API tokens or personal information, to prevent unintended exposure or storage. - - - -![Uptime alert expected request](./img/uptime-alert-expected-check-request.png) - -Below the request configuration, you'll find an example of the expected request that Sentry will send to the specified URL, including the method, headers, and body. Sentry automatically adds `User-Agent` and `Sentry-Trace` headers. - -Additional notes: - -- Include a `Content-Type` header if required by the target URL. For example, a JSON payload should have `Content-Type: application/json`. -- The selected interval affects downtime detection speed. Sentry triggers an uptime issue after three consecutive failures. For instance, with a 5-minute interval, downtime is detected at least 15 minutes after the first failure. Learn more about the [uptime check criteria](/product/uptime-monitoring/#uptime-check-criteria). -- In case the specified URL is behind a firewall, make sure Sentry's Uptime Bot can execute requests to it. Learn more about [firewall configuration with uptime monitoring](/product/uptime-monitoring/troubleshooting/#verify-firewall-configuration). -- Sentry Uptime Tracing automatically appends a sentry-trace header to outgoing requests for distributed tracing. [Learn more](/product/uptime-monitoring/uptime-tracing/). - -## 4. Alert Name - -Give your alert a descriptive name, for example, "Landing Page" or "Contact Page". - -## 5. Ownership - -Assign a team or team member to manage the alert. If no team is assigned, any user can modify the alert. [Uptime issues](/product/issues/issue-details/uptime-issues/) created from this alert rule will be set to the specified team or team member. diff --git a/docs/product/alerts/img/alert-details-example.png b/docs/product/alerts/img/alert-details-example.png deleted file mode 100644 index af4e7efb33e3f..0000000000000 Binary files a/docs/product/alerts/img/alert-details-example.png and /dev/null differ diff --git a/docs/product/alerts/img/alert-listing.png b/docs/product/alerts/img/alert-listing.png deleted file mode 100644 index e181340315abb..0000000000000 Binary files a/docs/product/alerts/img/alert-listing.png and /dev/null differ diff --git a/docs/product/alerts/img/issue-alert-rules.png b/docs/product/alerts/img/issue-alert-rules.png deleted file mode 100644 index 5ef9c9add95d4..0000000000000 Binary files a/docs/product/alerts/img/issue-alert-rules.png and /dev/null differ diff --git a/docs/product/alerts/img/issue-alert-status-page-example.png b/docs/product/alerts/img/issue-alert-status-page-example.png deleted file mode 100644 index ab92410526e7b..0000000000000 Binary files a/docs/product/alerts/img/issue-alert-status-page-example.png and /dev/null differ diff --git a/docs/product/alerts/index.mdx b/docs/product/alerts/index.mdx index 42bd87fc4285a..7a84d7d4b043c 100644 --- a/docs/product/alerts/index.mdx +++ b/docs/product/alerts/index.mdx @@ -1,84 +1,64 @@ --- title: Alerts -sidebar_order: 80 -description: >- - With Sentry Alerts, you can get real-time visibility into your code to quickly - resolve errors & update personal notifications to enhance the error and - performance monitoring experience for you and your team. Learn how to get - started here. +description: Create custom Alerts to pair with Monitors. +sidebar_order: 60 og_image: /og-images/product-alerts.png --- -Alerts provide real-time visibility into problems with your code and the impact on your users. There are several types of alerts available with customizable thresholds and integrations. +Sentry's Alerts help you take action when issues occur in your project. When an issue changes state, is created, or passes a threshold, an alert is triggered to perform external actions like sending notifications, creating tickets, or calling webhooks and integrations. Alerts must be paired with [Monitors](/product/monitors/) to run. -From the **Alerts** page in [sentry.io](https://sentry.io), you can create new alert rules and manage existing ones. The “Alert Rules” tab displays your existing alert rules, along with their current status, project, team, and creation date. By default, the list is filtered so that only alerts associated with the teams you're a member of, as well as ones that aren't associated with any team, are displayed. You can change this using the filter button. +### Some examples of when you could use an Alert +- Send a notification to your team's Slack channel when a new error occurs in an existing issue +- Create a ticket in JIRA when an issue is created and a team member is assigned +- Call a webhook or integration when an issue is created -![A list of alert rules, along with their status, project, team, and creation date.](./img/alert-listing.png) +[!alert-config](./img/alert-config.png) -The **Alerts** page also displays a “History” tab where you can find a list of metric alerts with information like when it was triggered and how long it was active. +## Creating an Alert -## Issue Alerts +To create an Alert, navigate to the [Alerts](https://sentry.io/issues/alerts/new/) page and click **Create Alert**. -[Issue alerts](/product/alerts/alert-types/#issue-alerts) trigger whenever any issue in a project matches specified criteria. You can create alerts for issue-level changes, such as: +{/* */} -- New issues -- Issue frequency increasing -- Resolved and archived issues becoming unresolved +### Set Triggers -You can find a full list of issue alert triggers in [Issue Alert Configuration](/product/alerts/create-alerts/issue-alert-config/#when-conditions-triggers). +A trigger is an action that must occur for the Alert to run. All trigger actions are issue state based. For example, you may want to send a notification to your team's Slack channel _when an issue is created_. You can select multiple triggers in a single Alert. They will run under an `ANY` condition, meaning that if any one of the triggers happen, the Alert will run. -## Metric Alerts for Errors & Performance +### Set Filters -[Metric alerts](/product/alerts/alert-types/#metric-alerts) trigger when a [metric](/product/insights/overview/metrics/) is breached for either error or transaction events. Use metric alerts to monitor a finite and known set of metrics and components you care about, such as error frequency or performance metrics in your entire project, on important pages, or with specific tags. +Filters are conditions that must be met for the Alert to run. For example, you may want to create a ticket _only for issues that are assigned to a specific team_ and _at a certain severity_. You can create multiple filters in a single Alert, and group them under either `ANY` or `ALL` conditions. For `ANY` conditions, if any one of the filters are true, the Alert will run. For `ALL` conditions, only if all of the filters are true, the Alert will run. -Create alerts to monitor specific metrics, such as: +### Add Actions -- Total errors in your project -- [Latency](/product/insights/overview/metrics/#latency): min, max, average, percentile -- [Failure rate](/product/insights/overview/metrics/#failure-rate) -- Crash free session or user rate for monitoring release health -- Custom metrics +Actions are the events that will be executed when the Alert is run. You can send notifications on any channel you're integrated with, create tickets, for example, in JIRA, or call a webhook or integration. You can set multiple actions in a single Alert. Learn more about Sentry's [integrations](/organization/integrations/). -You can find a full list of available metric alerts in [Metric Alerts](/product/alerts/alert-types/#metric-alerts). +**Note:** Some Monitors can only alert on certain integrations. See Sentry's [integrations](/organization/integrations/) for more information. -## Uptime Monitoring Alerts +## Connecting Alerts to Monitors -[Uptime alerts](/product/uptime-monitoring/) are triggered when an uptime HTTP check request fails to meet our -[uptime check criteria](/product/uptime-monitoring/#uptime-check-criteria). -You can use uptime alerts to make sure a specific URL is constantly available, even during periods of low or no traffic. +In order for Alerts to run, you need to connect them to at least one Monitor. To do so, select **Add Monitor** in the alert configuration page. You can add multiple monitors to an Alert. -## Creating Alerts +**Note**: If you set particular Environments as a filter in your Alert, it will only run for issues in those Environments, even if the Alert is connected to a Monitor that is filtered to different environments. -When you create a new project in [sentry.io](https://sentry.io), you can select a default issue alert. However, you can also [create your own alerts](/product/alerts/create-alerts/) to suit your team’s needs, using these [alert best practices](/product/alerts/best-practices/) as a guide. -## Muting Alerts +[!monitor-alerts](./img/monitor-alerts.png) -Alerts should notify you when there's an important problem with your application. But they shouldn't be too noisy, because that can lead to alert fatigue. Muting alerts is one way to reduce noise, but we recommend following these [alert best practices](/product/alerts/best-practices/) to help you create relevant alerts that notify the people equipped to fix the problem. +## Managing Alerts + +You can see a list of all your Alerts on the [Alerts](https://sentry.io/issues/alerts/) page. By default, Alerts are filtered down to your projects. -Any user can mute alerts for their entire organization by default, but users with manager or owner-level permissions can update the minimum role requirement by going to **Settings > General Settings > Let Members Create and Edit Alerts**. +Alerts are an Organization-level feature. By default, all team members can create and edit Alerts. You can update this setting in [Organization Membership settings](https://sentry.io/settings/organization/). -### Muting Issue Alerts - -Issue alerts can be muted on the **Alerts** details page by clicking the "Mute" button. This will keep the alert from notifying you until you click "Unmute". If you want to keep the alert from firing entirely, select "Mute for everyone" from the dropdown. If there's just one alert rule and it's set up to notify an entire integration, the only muting option will be "Mute for everyone". If there are multiple alert rules and they're set to notify both an integration and a user or a team, selecting "Mute for me" will only silence the alert for you, not the rest of the team. - -### Muting Metric Alerts - -Metric alerts work in the same way as Issue alerts and can be muted on the **Alerts** details page by clicking the "Mute" button. +By clicking on an Alert, you can view the details, edit the Alert, or turn it on or off. -## Disabled Alerts +The details page will show a high level chart of how often the Alert has run, a list of the most recent runs, the configuration, and connected monitors. -Sentry has disabled duplicate alerts and alerts with no actions. - -Anyone with [alert edit access](/organization/membership/) can re-enable an alert by editing its conditions and re-saving it. Alerts need to pass Sentry’s checks before they can be saved. See [best practices](/product/alerts/best-practices/) for guidance on writing useful alerts. +[!alert-details](./img/alert-details.png) ## Notifications -Besides alerts, Sentry sends you notifications about various things like [issue state changes](/product/issues/states-triage/), [release deploys](/product/releases/), and [quota usage](/pricing/quotas/). You can fine-tune these notifications, as well as your personal alert settings, in **User Settings > Notifications**. Learn more about notifications and adjusting their associated settings in [the full documentation](/product/alerts/notifications/). - -## Learn more - - +Besides Alerts, Sentry sends you notifications about various things like [issue state changes](/product/issues/states-triage/), [release deploys](/product/releases/), and [quota usage](/pricing/quotas/). You can fine-tune these notifications, as well as your personal alert settings, in **User Settings > Notifications**. Learn more about notifications and adjusting their associated settings in [the full documentation](/product/alerts/notifications/). \ No newline at end of file diff --git a/docs/product/alerts/notifications/index.mdx b/docs/product/alerts/notifications/index.mdx index c2feec1a91bed..66a7b6a689220 100644 --- a/docs/product/alerts/notifications/index.mdx +++ b/docs/product/alerts/notifications/index.mdx @@ -1,5 +1,5 @@ --- -title: Notifications +title: Sentry Notifications sidebar_order: 40 description: >- Learn about the types of notifications that Sentry sends you, and how to diff --git a/docs/product/index.mdx b/docs/product/index.mdx index 3dced685a84ac..730cc143ab6ac 100644 --- a/docs/product/index.mdx +++ b/docs/product/index.mdx @@ -50,11 +50,11 @@ Our [**AI Agents Monitoring**](/product/insights/ai/agents/) feature gives you i ### Uptime Monitoring -Sentry's [**Uptime Monitoring**](/product/uptime-monitoring/) helps you maintain uptime for your web services by monitoring relevant URLs. It continuously tracks configured URLs, delivering alerts and insights to quickly identify downtime and troubleshoot issues. By leveraging [distributed tracing](/product/uptime-monitoring/uptime-tracing/), Sentry enables you to pinpoint any errors that occur during an uptime check, simplifying triage and accelerating root cause analysis. Uptime monitoring includes [uptime request spans](/product/uptime-monitoring/#uptime-request-spans) by default. These act as the root of any uptime issue's trace, giving you better context for faster debugging. +Sentry's [**Uptime Monitoring**](/product/monitors/uptime-monitoring/) helps you maintain uptime for your web services by monitoring relevant URLs. It continuously tracks configured URLs, delivering alerts and insights to quickly identify downtime and troubleshoot issues. By leveraging [distributed tracing](/product/monitors/uptime-monitoring/uptime-tracing/), Sentry enables you to pinpoint any errors that occur during an uptime check, simplifying triage and accelerating root cause analysis. Uptime monitoring includes [uptime request spans](/product/monitors/uptime-monitoring/#uptime-request-spans) by default. These act as the root of any uptime issue's trace, giving you better context for faster debugging. ### Recurring Job Monitoring -[**Cron Monitors**](/product/crons/) allows you to monitor the uptime and performance of any scheduled, recurring job in Sentry. Once implemented, it'll allow you to get alerts and metrics to help you solve errors, detect timeouts, and prevent disruptions to your service. +[**Cron Monitors**](/product/monitors/crons/) allows you to monitor the uptime and performance of any scheduled, recurring job in Sentry. Once implemented, it'll allow you to get alerts and metrics to help you solve errors, detect timeouts, and prevent disruptions to your service. ### Visibility Into Your Data Across Environments diff --git a/docs/product/issues/issue-details/uptime-issues/index.mdx b/docs/product/issues/issue-details/uptime-issues/index.mdx index dd92ff837a4fd..d658708309be8 100644 --- a/docs/product/issues/issue-details/uptime-issues/index.mdx +++ b/docs/product/issues/issue-details/uptime-issues/index.mdx @@ -9,7 +9,7 @@ og_image: /og-images/product-issues-issue-details-uptime-issues.png An uptime issue is a grouping of detected downtime events for a specific URL. A downtime event is generated by active uptime alerts when HTTP requests fail to meet our -[uptime check criteria](/product/uptime-monitoring/#uptime-check-criteria). +[uptime check criteria](/product/monitors/uptime-monitoring/#uptime-check-criteria). ![Uptime issue details](./img/uptime-issue-details.png) @@ -20,4 +20,4 @@ Uptime checks made against web services configured with one of Sentry's supporte ## Issue Lifecycle -Uptime issues are grouped by the monitored URL and created upon the first detected downtime. Sentry automatically resolves an ongoing uptime issue when the monitored URL returns to a healthy status and meets our [uptime check criteria](/product/uptime-monitoring/#uptime-check-criteria). If the URL experiences subsequent downtime, the issue's status will change to regressed. +Uptime issues are grouped by the monitored URL and created upon the first detected downtime. Sentry automatically resolves an ongoing uptime issue when the monitored URL returns to a healthy status and meets our [uptime check criteria](/product/monitors/uptime-monitoring/#uptime-check-criteria). If the URL experiences subsequent downtime, the issue's status will change to regressed. diff --git a/docs/product/issues/monitors-and-alerts/index.mdx b/docs/product/issues/monitors-and-alerts/index.mdx new file mode 100644 index 0000000000000..2bf917954b680 --- /dev/null +++ b/docs/product/issues/monitors-and-alerts/index.mdx @@ -0,0 +1,55 @@ +--- +title: Monitors and Alerts +sidebar_order: 10 +description: "Learn how Monitors and Alerts help you customize your issue management process." +--- + +[Monitors](/product/monitors/) and [Alerts](/product/alerts/) work together to help you create issues and take action when problems occur in your project. While they serve different purposes, they're designed to work as a team. + +## How They Work Together + +**Monitors** are the "detectors" - they watch for specific conditions and create issues when those conditions are met. **Alerts** are the "responders" - they take action when issues are created or change state and meet the filter criteria of the Alert. + +Here's the typical flow: + +1. **Monitor detects a problem** → Creates an issue +2. **Issue triggers Alert** → Takes external action (sends notifications, creates tickets, calls webhooks) + +[!monitors-and-alerts-flow-chart](./img/monitors-and-alerts-flow-chart.png) + +## Monitors: Creating Issues + +Monitors customize when errors and performance problems become issues. They can track: + +- **Custom metrics** and span attributes +- **Scheduled jobs** (cron monitors) +- **HTTP endpoints** (uptime monitors) +- **Default behaviors** (errors, replays, traces, profiles) + +[See all Monitor types](/product/monitors/#types-of-monitors) + +When a monitor's conditions are met, it automatically creates an issue with the specified priority, assignee, and other attributes. + +## Alerts: Taking Action + +Alerts respond to issue state changes by performing external actions like: + +- Sending notifications to Slack, email, or other channels +- Creating tickets in JIRA or other project management tools +- Calling webhooks or integrations + +## The Connection + +Alerts must be connected to Monitors to run. This connection ensures that: + +- Issues created by Monitors can trigger appropriate responses +- You have full control over both detection and response +- Actions are taken only for the issues you care about + +## Getting Started + +1. **Create a Monitor** to define when issues should be created +2. **Create an Alert** to define what actions to take +3. **Connect them** so the Alert responds to issues from that Monitor + +Using Monitors and Alerts gives you a complete workflow from problem detection to team notification, ticket creation, and more. \ No newline at end of file diff --git a/docs/product/crons/alerts-backend-insights-migration.mdx b/docs/product/monitors/crons/alerts-backend-insights-migration.mdx similarity index 100% rename from docs/product/crons/alerts-backend-insights-migration.mdx rename to docs/product/monitors/crons/alerts-backend-insights-migration.mdx diff --git a/docs/product/crons/getting-started/http/index.mdx b/docs/product/monitors/crons/getting-started/http/index.mdx similarity index 100% rename from docs/product/crons/getting-started/http/index.mdx rename to docs/product/monitors/crons/getting-started/http/index.mdx diff --git a/docs/product/crons/getting-started/index.mdx b/docs/product/monitors/crons/getting-started/index.mdx similarity index 95% rename from docs/product/crons/getting-started/index.mdx rename to docs/product/monitors/crons/getting-started/index.mdx index d44c8c6413cc6..a0abb984007fe 100644 --- a/docs/product/crons/getting-started/index.mdx +++ b/docs/product/monitors/crons/getting-started/index.mdx @@ -31,5 +31,5 @@ We're working on enabling additional platforms for Crons. In the meantime, you c ## Others -- [HTTP](/product/crons/getting-started/http/) +- [HTTP](/product/monitors/crons/getting-started/http/) - [Sentry CLI](/cli/crons/) diff --git a/docs/product/crons/img/crons-as-alerts-guide.png b/docs/product/monitors/crons/img/crons-as-alerts-guide.png similarity index 100% rename from docs/product/crons/img/crons-as-alerts-guide.png rename to docs/product/monitors/crons/img/crons-as-alerts-guide.png diff --git a/docs/product/crons/img/crons-as-backend-insights.png b/docs/product/monitors/crons/img/crons-as-backend-insights.png similarity index 100% rename from docs/product/crons/img/crons-as-backend-insights.png rename to docs/product/monitors/crons/img/crons-as-backend-insights.png diff --git a/docs/product/crons/index.mdx b/docs/product/monitors/crons/index.mdx similarity index 85% rename from docs/product/crons/index.mdx rename to docs/product/monitors/crons/index.mdx index a331012ca189b..fe82fb90f80ca 100644 --- a/docs/product/crons/index.mdx +++ b/docs/product/monitors/crons/index.mdx @@ -1,6 +1,6 @@ --- title: "Cron Monitoring" -sidebar_order: 70 +sidebar_order: 40 description: "Monitor your recurring jobs with Sentry to help maintain uptime and performance." --- @@ -16,9 +16,9 @@ To use Cron Monitoring, you must have an existing Sentry account and project set ## Learn More About Cron Monitoring -- [Set Up](/product/crons/getting-started/) +- [Set Up](/product/monitors/crons/getting-started/) Learn how to set up Sentry's job monitoring feature using our CLI, HTTP, and supported SDKs. -- [Job Monitoring](/product/crons/job-monitoring/) +- [Job Monitoring](/product/monitors/crons/job-monitoring/) Get a product walkthrough of our Job Monitoring feature. -- [Troubleshooting](/product/crons/troubleshooting/) +- [Troubleshooting](/product/monitors/crons/troubleshooting/) Get troubleshooting help. diff --git a/docs/product/crons/job-monitoring.mdx b/docs/product/monitors/crons/job-monitoring.mdx similarity index 100% rename from docs/product/crons/job-monitoring.mdx rename to docs/product/monitors/crons/job-monitoring.mdx diff --git a/docs/product/crons/legacy-endpoint-migration.mdx b/docs/product/monitors/crons/legacy-endpoint-migration.mdx similarity index 98% rename from docs/product/crons/legacy-endpoint-migration.mdx rename to docs/product/monitors/crons/legacy-endpoint-migration.mdx index dd2cd4184a496..734a822a5a644 100644 --- a/docs/product/crons/legacy-endpoint-migration.mdx +++ b/docs/product/monitors/crons/legacy-endpoint-migration.mdx @@ -61,7 +61,7 @@ There are a few backward incompatible changes to be aware of. also been removed. You will always use `POST` or `GET` for Check-Ins. - For [overlapping - jobs](/product/crons/getting-started/http/#overlapping-jobs-optional), it is + jobs](/product/monitors/crons/getting-started/http/#overlapping-jobs-optional), it is still possible to specify a `check_in_id` via the query parameters or JSON body. However, the API no longer responds with an auto-generated Check-In ID. If you need a stable Check-In ID, you must generate it diff --git a/docs/product/crons/troubleshooting.mdx b/docs/product/monitors/crons/troubleshooting.mdx similarity index 90% rename from docs/product/crons/troubleshooting.mdx rename to docs/product/monitors/crons/troubleshooting.mdx index 1c7878467c9a6..73d6758f80ee3 100644 --- a/docs/product/crons/troubleshooting.mdx +++ b/docs/product/monitors/crons/troubleshooting.mdx @@ -31,13 +31,13 @@ If the monitor environment continues to be broken after an additional 14 days, w -You may not have [linked errors to your monitor](/product/crons/getting-started/http/#connecting-errors-to-cron-monitors). +You may not have [linked errors to your monitor](/product/monitors/crons/getting-started/http/#connecting-errors-to-cron-monitors). -You may not have [set up alerts for your monitor](/product/crons/getting-started/http/#alerts). +You may not have [set up alerts for your monitor](/product/monitors/crons/getting-started/http/#alerts). diff --git a/docs/product/monitors/index.mdx b/docs/product/monitors/index.mdx new file mode 100644 index 0000000000000..f13a604e456fc --- /dev/null +++ b/docs/product/monitors/index.mdx @@ -0,0 +1,90 @@ +--- +title: Monitors +description: Generate issues and trigger alerts by creating custom monitors to track errors, performance, and metrics. +sidebar_order: 70 +--- + +Sentry's Monitors are used to customize when to turn errors and performance problems into issues. They can be configured using conditional rules to create issues when specific criteria are met. For example, you could monitor when the duration of a transaction takes longer than 3 seconds on a particular browser. Further automate your issue creation experience using Monitors to automatically add assignees and set different priorities based on severity. + +## Types of Monitors + +### Custom Monitors + +You can use Custom Monitors to track errors based on span attributes and custom metrics, the uptime and performance of any scheduled, recurring job, or the uptime and performance of any HTTP request. + +- [Metric Monitors](#metric-monitor-settings): Track for errors based on span attributes and custom metrics. +- [Cron Monitors](/product/monitors/crons/): Track the uptime and performance of any scheduled, recurring job. +- [Uptime Monitors](placeholder): Track the uptime and performance of any HTTP request. + +### Default Monitors + +Sentry also provides default monitors that are automatically created for you when you create a new project. + +- **Error Monitor**: The default monitor based on [issue grouping/fingerprint rules](/concepts/data-management/event-grouping/) +- **Replay Monitor**: Once you've configured [Session Replay](/product/explore/session-replay/), issues will be created via the Replay Monitor +- **Trace Monitor**: Once you've configured [Tracing](/product/tracing/), issues will be created via the Trace Monitor +- **Profile Monitor**: Once you've configured [Profiling](/product/explore/profiling/), issues will be created via the Profile Monitor + +## Creating a Monitor +To create a Monitor, navigate to the [Monitors](https://sentry.io/issues/monitors/new/) page and click **Create Monitor**. You can choose between the three types of Monitors (metric, cron, and uptime). Each one will have a separate configuration process. + +### General Settings + +Monitors are made of attributes that define when to create an issue, and actions that define what to do when an issue is created. + +- Name the Monitor +- Select the project, and in some cases, the environment +- Select attributes based on the Monitor type +- Set priority based on attributes +- Set the assignee +- Set auto-resolve based on attributes +- Connect [Custom Alerts](/product/automations/custom-automations/) like notifications and ticket creation +to pair with your Monitor + + + +Assignees set by [ownership rules](/product/issues/ownership-rules/) will override assignees set by Monitors. + + + +{/* */} + +### Metric Monitor Settings + +Metric Monitors are used to track errors based on span attributes and custom metrics. + +[!metric-monitor-config](./img/metric-monitor-config.png) + +Choose the metric, the interval for how often to check, and the way you want to monitor for changes. You can choose an absolute number threshold, a percentage change, or dynamic anomaly detection. + +### Cron Monitor Settings + +Cron Monitors are used to track the uptime and performance of any scheduled, recurring job. + +[!cron-monitor-config](./img/cron-monitor-config.png) + +Choose the schedule for how often to check, set the check-in margin, the max runtime, and failure tolerance. + +### Uptime Monitor Settings + +Uptime Monitors are used to track the uptime and performance of any HTTP request. + +[!uptime-monitor-config](./img/uptime-monitor-config.png) + +Choose the URL and HTTP request you wish to monitor. Set the interval, timeout, and any headers you wish to include. + +## Managing Monitors + +You can see a list of all your Monitors on the [Monitors](https://sentry.io/issues/monitors/) page. Select a Monitor type at the top of the page to narrow down the list. By default, Monitors are filtered down to your projects. + + + +Monitors are a Project-level feature, but the permission set is organization-level. By default, all members can create and edit Monitors. You can update this setting in [Organization Membership settings](https://sentry.io/settings/organization/). + + + +By clicking on a Monitor, you can view the details, edit the Monitor, or disable it. + +The details page will show a high level chart of the Monitor's performance, the configuration, created issue, and connected automations. + +[!monitor-details](./img/monitor-details.png) \ No newline at end of file diff --git a/docs/product/uptime-monitoring/automatic-detection.mdx b/docs/product/monitors/uptime-monitoring/automatic-detection.mdx similarity index 92% rename from docs/product/uptime-monitoring/automatic-detection.mdx rename to docs/product/monitors/uptime-monitoring/automatic-detection.mdx index 631b8a2d3bde4..264d9e3148f83 100644 --- a/docs/product/uptime-monitoring/automatic-detection.mdx +++ b/docs/product/monitors/uptime-monitoring/automatic-detection.mdx @@ -4,7 +4,7 @@ sidebar_order: 51 description: "Learn how automatic detection of uptime monitoring works." --- -In order to be able to automatically detect uptime alerts, we analyze all the URLs detected in your project's captured error data to find the hostname that appears most frequently. This helps ensure that your most critical hostname is continuously monitored, enhancing the reliability and availability of your web services. We then create an uptime alert if it passes our [uptime check criteria](/product/uptime-monitoring/#uptime-check-criteria). Automatic uptime checks are configured to run once a minute as GET requests. +In order to be able to automatically detect uptime alerts, we analyze all the URLs detected in your project's captured error data to find the hostname that appears most frequently. This helps ensure that your most critical hostname is continuously monitored, enhancing the reliability and availability of your web services. We then create an uptime alert if it passes our [uptime check criteria](/product/monitors/uptime-monitoring/#uptime-check-criteria). Automatic uptime checks are configured to run once a minute as GET requests. The automatic creation of Uptime Monitors only happens if there are no other existing uptime monitors configured. diff --git a/docs/product/uptime-monitoring/img/allow-sampling-new.png b/docs/product/monitors/uptime-monitoring/img/allow-sampling-new.png similarity index 100% rename from docs/product/uptime-monitoring/img/allow-sampling-new.png rename to docs/product/monitors/uptime-monitoring/img/allow-sampling-new.png diff --git a/docs/product/uptime-monitoring/img/uptime-issue-alert-rule.png b/docs/product/monitors/uptime-monitoring/img/uptime-issue-alert-rule.png similarity index 100% rename from docs/product/uptime-monitoring/img/uptime-issue-alert-rule.png rename to docs/product/monitors/uptime-monitoring/img/uptime-issue-alert-rule.png diff --git a/docs/product/uptime-monitoring/img/uptime-request-span.png b/docs/product/monitors/uptime-monitoring/img/uptime-request-span.png similarity index 100% rename from docs/product/uptime-monitoring/img/uptime-request-span.png rename to docs/product/monitors/uptime-monitoring/img/uptime-request-span.png diff --git a/docs/product/uptime-monitoring/index.mdx b/docs/product/monitors/uptime-monitoring/index.mdx similarity index 94% rename from docs/product/uptime-monitoring/index.mdx rename to docs/product/monitors/uptime-monitoring/index.mdx index f329380dba80e..e70667cf7c33c 100644 --- a/docs/product/uptime-monitoring/index.mdx +++ b/docs/product/monitors/uptime-monitoring/index.mdx @@ -13,7 +13,7 @@ By leveraging [distributed tracing](/concepts/key-terms/tracing/distributed-trac ## Set Up -Uptime is [automatically configured](/product/uptime-monitoring/automatic-detection/) as a new alert for the most frequently encountered hostname in all URLs of your error data, ensuring continuous monitoring of your most critical hostname right out of the box. +Uptime is [automatically configured](/product/monitors/uptime-monitoring/automatic-detection/) as a new alert for the most frequently encountered hostname in all URLs of your error data, ensuring continuous monitoring of your most critical hostname right out of the box. You can also [create uptime monitoring alerts](/product/alerts/create-alerts/) for specific URLs. They're fully customizable with request details such as the HTTP method, headers, and body. diff --git a/docs/product/uptime-monitoring/troubleshooting.mdx b/docs/product/monitors/uptime-monitoring/troubleshooting.mdx similarity index 93% rename from docs/product/uptime-monitoring/troubleshooting.mdx rename to docs/product/monitors/uptime-monitoring/troubleshooting.mdx index d5e44e5e582b2..cddd7009dd8c1 100644 --- a/docs/product/uptime-monitoring/troubleshooting.mdx +++ b/docs/product/monitors/uptime-monitoring/troubleshooting.mdx @@ -15,7 +15,7 @@ If you need to configure your firewall allowlist to include Sentry's Uptime Bot, Our uptime check requests use the following `User-Agent`: ``` -SentryUptimeBot/1.0 (+http://docs.sentry.io/product/uptime-monitoring/) +SentryUptimeBot/1.0 (+http://docs.sentry.io/product/monitors/uptime-monitoring/) ``` ### IP Addresses diff --git a/docs/product/uptime-monitoring/uptime-tracing.mdx b/docs/product/monitors/uptime-monitoring/uptime-tracing.mdx similarity index 97% rename from docs/product/uptime-monitoring/uptime-tracing.mdx rename to docs/product/monitors/uptime-monitoring/uptime-tracing.mdx index 35d904e512f18..d6f91ec25aa02 100644 --- a/docs/product/uptime-monitoring/uptime-tracing.mdx +++ b/docs/product/monitors/uptime-monitoring/uptime-tracing.mdx @@ -9,7 +9,7 @@ Sentry's Uptime Monitoring uses [distributed tracing](/product/tracing/#whats-di When uptime checks are performed, Sentry creates a **trace** that shows the complete request lifecycle. This trace contains: -- **Uptime request spans**: A [default set of root spans](/product/uptime-monitoring/#uptime-request-spans) that identifies this as an uptime check +- **Uptime request spans**: A [default set of root spans](/product/monitors/uptime-monitoring/#uptime-request-spans) that identifies this as an uptime check - **Application spans**: Individual operations like database queries, API calls, and cache operations, configured through distributed tracing - **Error events**: Any exceptions or failures that occur during the request @@ -26,7 +26,7 @@ Example Uptime check request: ```HTTP GET /example-uptime-endpoint HTTP/1.1 Host: sentry.io -User-Agent: SentryUptimeBot/1.0 (+http://docs.sentry.io/product/uptime-monitoring/) +User-Agent: SentryUptimeBot/1.0 (+http://docs.sentry.io/product/monitors/uptime-monitoring/) Sentry-Trace: 32d4011600324838afcd666edadc1d09-8d5ca7419a02ca36 ``` diff --git a/docs/security-legal-pii/security/data-retention-periods.mdx b/docs/security-legal-pii/security/data-retention-periods.mdx index de3e9b0b513cd..be385504a4afc 100644 --- a/docs/security-legal-pii/security/data-retention-periods.mdx +++ b/docs/security-legal-pii/security/data-retention-periods.mdx @@ -14,14 +14,14 @@ By default, new account trials have Team plan retention. If you are trialing fro | Data Type | Developer | Team | Business / Enterprise | |-----------|-----------|------|----------| -| Errors | 30 days | 90 days | 90 days | -| Logs | 30 days | 30 days | 30 days | -| Spans/Transactions | 30 days | 30 days* | 30 days + 13 months sampled* | -| Session Replays | 30 days | 90 days | 90 days | -| Profiles | 30 days | 30 days | 30 days | -| Crons | 30 days | 30 days | 30 days | -| Uptime | 30 days | 90 days | 90 days | -| Attachments | 30 days | 90 days | 90 days | +| [Errors](/concepts/key-terms/enrich-data/) | 30 days | 90 days | 90 days | +| [Logs](/product/explore/logs/) | 30 days | 30 days | 30 days | +| [Spans/Transactions](/concepts/key-terms/tracing/distributed-tracing/) | 30 days | 30 days* | 30 days + 13 months sampled* | +| [Session Replays](/product/explore/session-replay/web/) | 30 days | 90 days | 90 days | +| [Profiles](/product/explore/profiling/) | 30 days | 30 days | 30 days | +| [Crons](/product/monitors/crons/) | 30 days | 30 days | 30 days | +| [Uptime](/product/monitors/uptime-monitoring/) | 30 days | 90 days | 90 days | +| [Attachments](/product/issues/issue-details/attachments/) | 30 days | 90 days | 90 days | **Exception\*:** If you are on a[Team or Business plan](https://sentry.io/settings/billing/overview/) that uses [transaction-based billing](https://docs.sentry.io/pricing/), transactions retention will be 90 days and sampled retention of spans data will not apply. diff --git a/docs/security-legal-pii/security/ip-ranges.mdx b/docs/security-legal-pii/security/ip-ranges.mdx index 48b50cd008829..d4da394eaacf4 100644 --- a/docs/security-legal-pii/security/ip-ranges.mdx +++ b/docs/security-legal-pii/security/ip-ranges.mdx @@ -158,7 +158,7 @@ This endpoint returns a newline-separated list of all current Uptime Monitoring -Uptime Monitoring IP addresses may change over time. If you need to programmatically verify whether a visitor is a Sentry bot, we recommend checking the [user agent](/product/uptime-monitoring/troubleshooting/#user-agent) instead. +Uptime Monitoring IP addresses may change over time. If you need to programmatically verify whether a visitor is a Sentry bot, we recommend checking the [user agent](/product/monitors/uptime-monitoring/troubleshooting/#user-agent) instead.