diff --git a/docs/organization/data-storage-location/index.mdx b/docs/organization/data-storage-location/index.mdx index 00ba4bc2ef0ea..568a6441b886b 100644 --- a/docs/organization/data-storage-location/index.mdx +++ b/docs/organization/data-storage-location/index.mdx @@ -55,6 +55,18 @@ Here’s a list of the types of data that may be stored in the US. Metadata that lets Sentry identify an organization will be replicated out of the organization's data storage location to facilitate login, and backwards-compatible APIs. You can always confirm the location of your organization by viewing your organization's settings page. +### Data Stored in All Locations (US and EU) + +Here’s a list of the types of data that will be stored in both data storage location (US and EU). + +- Uptime checks + + + +For uptime monitoring to work effectively, we perform uptime checks from multiple geolocations. As a result, uptime check data may be stored outside your selected data region, beyond the storage commitments outlined on this page. + + + ## Using Data Storage Location APIs To ensure that your API requests are only processed within your selected data storage location, use the region-specific domain: @@ -93,6 +105,7 @@ If you have a self-hosted Sentry account, you can [follow these instructions](/c - Profiles - Session Replays - Cron check-ins +- Uptime checks - DSN keys - Release health - Releases, Debug Symbols, and source maps diff --git a/docs/organization/early-adopter-features/index.mdx b/docs/organization/early-adopter-features/index.mdx index f847a588b158a..670ba62ea000d 100644 --- a/docs/organization/early-adopter-features/index.mdx +++ b/docs/organization/early-adopter-features/index.mdx @@ -21,6 +21,5 @@ Limitations: - [Issue Status](/product/issues/states-triage/) tags - [Span Summary](/product/performance/transaction-summary/#span-summary) - [Investigation Mode](/product/performance/retention-priorities/#investigation-mode) for retention priorities in Tracing -- [Uptime Monitoring](/product/alerts/uptime-monitoring/) - [Dynamic Alerts](/product/alerts/create-alerts/metric-alert-config/#dynamic-alerts) - [New Trace Explorer With Span Metrics](/product/explore/new-trace-explorer/) diff --git a/docs/pricing/index.mdx b/docs/pricing/index.mdx index 14c101d94ca78..f791d40a2ac3e 100644 --- a/docs/pricing/index.mdx +++ b/docs/pricing/index.mdx @@ -76,15 +76,15 @@ Tracing is enabled by and will be billed for in spans. #### Cron Monitors Pricing -All Sentry plans include **one cron monitor**. To activate additional monitors, set up a **Pay-As-You-Go (PAYG) budget**. Additional monitors can't be purchased in advance; they are only available through your PAYG budget, which can be shared across all event types. +All Sentry plans include **one cron monitor**. To activate additional cron monitors, set up a **Pay-As-You-Go (PAYG) budget**. Additional cron monitors can't be purchased in advance; they are only available through your PAYG budget, which can be shared across all event types. **Key Points:** -- **Deactivating or Deleting Monitors**: +- **Deactivating or Deleting Cron Monitors**: - Deactivated or deleted monitors will **count** towards your billing quota if they were previously active in the current billing period. Otherwise, they won't count towards your billing quota. - Their quota becomes **reusable** within the **same billing period**. -- **Activating Monitors**: - - Sentry first uses any **reusable quota** from monitors deactivated or deleted in the current billing period. +- **Activating Cron Monitors**: + - Sentry first uses any **reusable quota** from cron monitors deactivated or deleted in the current billing period. - If none is available, your **reserved quota** or **PAYG budget** is used. @@ -93,23 +93,61 @@ All Sentry plans include **one cron monitor**. To activate additional monitors, - **Quota Reuse Limitations**: - Only available **within the same billing period**. - - Applies to monitors that were previously active and billed. + - Applies to cron monitors that were previously active and billed. - **Reusable Quota Does Not Carry Over**: - Reusable quota **does not carry over** to new billing periods. -**Monitors Across Billing Periods:** +**Cron Monitors Across Billing Periods:** -- Monitors remain active across billing periods if you have sufficient **reserved quota** or **PAYG budget**. -- Monitors may be automatically deactivated if there's insufficient budget. -- Monitors that have been manually deactivated or deleted remain in that state. +- Cron monitors remain active across billing periods if you have sufficient **reserved quota** or **PAYG budget**. +- Cron monitors may be automatically deactivated if there's insufficient budget. +- Cron monitors that have been manually deactivated or deleted remain in that state. | Team PAYG | Business PAYG | | ---------- | -------------- | | $0.7800000 | $0.7800000 | +#### Uptime Monitors Pricing + +All Sentry plans include **one uptime monitor**. To activate additional uptime monitors, set up a **Pay-As-You-Go (PAYG) budget**. Additional uptime monitors can't be purchased in advance; they are only available through your PAYG budget, which can be shared across all event types. + +**Key Points:** + +- **Deactivating or Deleting Uptime Monitors**: + - Deactivated or deleted uptime monitors will **count** towards your billing quota only if they were previously active in the current billing period. + - Their quota becomes **reusable** within the **same billing period**. +- **Activating Uptime Monitors**: + - Sentry first uses any **reusable quota** from uptime monitors deactivated or deleted in the current billing period. + - If none is available, your **reserved quota** or **PAYG budget** is used. + + + +**Important:** + +- **Quota Reuse Limitations**: + - Only available **within the same billing period**. + - Applies to uptime monitors that were previously active and billed. +- **Reusable Quota Does Not Carry Over**: + - Reusable quota **does not carry over** to new billing periods. + + + +**Uptime Monitors Across Billing Periods:** + +- Uptime monitors remain active across billing periods if you have sufficient **reserved quota** or **PAYG budget**. +- Uptime monitors may be automatically deactivated if there's insufficient budget. +- Uptime monitors that have been manually deactivated or deleted remain in that state. + + +| Team PAYG | Business PAYG | +| ---------- | -------------- | +| $1.00 | $1.00 | + + + #### Attachments Pricing (per GB) | Attachment Size | Team Reserved | Team PAYG | Business Reserved | Business PAYG | diff --git a/docs/product/alerts/alert-types.mdx b/docs/product/alerts/alert-types.mdx index dc41e454b8493..9cd377dd3c63a 100644 --- a/docs/product/alerts/alert-types.mdx +++ b/docs/product/alerts/alert-types.mdx @@ -116,14 +116,13 @@ The **Alert Details** page also includes a list of suspect issues or transaction ## Uptime Alerts - - Uptime alerts trigger whenever an uptime check request fails to meet our [uptime check criteria](/product/alerts/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 -### Alert Details Page +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 shows a list of uptime issues that were created by the alert. Clicking on any of the issues will take you to a page with additional information that may help you debug that issue. +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 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 new file mode 100644 index 0000000000000..2605d050c4401 Binary files /dev/null and b/docs/product/alerts/create-alerts/img/uptime-alert-expected-check-request.png 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 new file mode 100644 index 0000000000000..286f6886bd11b Binary files /dev/null and b/docs/product/alerts/create-alerts/img/uptime-alert-request-config.png differ diff --git a/docs/product/alerts/create-alerts/uptime-alert-config.mdx b/docs/product/alerts/create-alerts/uptime-alert-config.mdx index 787d7e3227a23..19a6bc7a0ad7a 100644 --- a/docs/product/alerts/create-alerts/uptime-alert-config.mdx +++ b/docs/product/alerts/create-alerts/uptime-alert-config.mdx @@ -4,42 +4,53 @@ sidebar_order: 30 description: "Learn more about the options for configuring an uptime alert." --- - - 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. -You'll notice that the “Environment” dropdown list you see here shows the same environments as the “Environment” dropdown in your project (not including hidden environments). +The “Environment” dropdown lists the same environments available in your project, excluding hidden ones. ## 2. Project -Specify which project your alert rule belongs to so that any [uptime issues](/product/issues/issue-details/uptime-issues/) you create will show up for that specific 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 -Configure how Sentry should execute an HTTP uptime check, by specifying: +![Uptime alert request configuration](./img/uptime-alert-request-config.png) -- **URL**: The URL for which Sentry should execute an uptime check request. -- **Method**: The request method used to execute the uptime check. Available options are `GET`, `POST`, `HEAD`, `PUT`, `DELETE`, `PATCH`, and `OPTIONS`. -- **Headers**: The request headers included in the uptime check request. -- **Body**: The body message to include in the uptime check request. (This is only available when the method is set to `POST`, `PUT`, and `PATCH`.) -- **Allow Sampling**: Enable "Allow Sampling" to let the Sentry SDK handle span sampling for requests. See the [distributed tracing with uptime](/product/alerts/uptime-monitoring/uptime-tracing/) docs for more detail. +Configure how Sentry performs HTTP uptime checks by setting the following options: -Make sure to include a `Content-Type` header in your headers configuration in case the specified URL requires it. For example, a JSON message body would have a `Content-Type` header of `application/json`. +- **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/alerts/uptime-monitoring/uptime-tracing/) for details. -If the specified URL is behind a firewall, make sure Sentry's Uptime Bot can execute requests to it. [Learn more](/product/alerts/uptime-monitoring/troubleshooting/#verify-firewall-configuration). +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/alerts/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/alerts/uptime-monitoring/troubleshooting/#verify-firewall-configuration). +- Sentry Uptime Tracing automatically appends a sentry-trace header to outgoing requests for distributed tracing. [Learn more](/product/alerts/uptime-monitoring/uptime-tracing/). + ## 4. Alert Name Give your alert a descriptive name, for example, "Landing Page" or "Contact Page". ## 5. Ownership -Lastly, choose a team to associate with your alert so that members of that team are able to edit the alert if they want to. Note, that you can only add teams that you're a member of. If no team is assigned, anyone will be able to edit the alert. +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/uptime-monitoring/automatic-detection.mdx b/docs/product/alerts/uptime-monitoring/automatic-detection.mdx index 60516ece0213f..144ead13d3bf0 100644 --- a/docs/product/alerts/uptime-monitoring/automatic-detection.mdx +++ b/docs/product/alerts/uptime-monitoring/automatic-detection.mdx @@ -4,11 +4,9 @@ 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/alerts/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. To avoid creating flaky alerts, the hostname undergoes an "onboarding period" of three days. During this period, we send HTTP requests to the hostname every hour. If the request fails three times or more, the hostname will be dropped and re-evaluated after seven days. diff --git a/docs/product/alerts/uptime-monitoring/index.mdx b/docs/product/alerts/uptime-monitoring/index.mdx index 9708b1dacc0a8..3bab78517599c 100644 --- a/docs/product/alerts/uptime-monitoring/index.mdx +++ b/docs/product/alerts/uptime-monitoring/index.mdx @@ -4,8 +4,6 @@ sidebar_order: 50 description: "Learn how to help maintain uptime for your web services by monitoring relevant URLs with Sentry's Uptime Monitoring." --- - - Sentry's Uptime Monitoring lets you monitor the availability and reliability of your web services effortlessly. Once enabled, it continuously tracks configured URLs, delivering instant alerts and insights to quickly identify downtime and troubleshoot issues. By leveraging [distributed tracing](/concepts/key-terms/tracing/distributed-tracing/), Sentry enables you to pinpoint any errors that occur during an uptime check, simplifying triage and accelerating root cause analysis. This helps you enhance both the reliability and uptime of your web services. @@ -30,10 +28,16 @@ Our uptime monitoring system verifies the availability of your URLs by performin If a DNS issue is detected, the check will be marked as a failure, allowing you to address the underlying connectivity problems. -## Notifications +### Uptime Check Failures + +An uptime alert continuously monitors the configured URL with the criteria defined above. If a failure occurs, +a new [uptime issue](/product/issues/issue-details/uptime-issues/) is created, including details about the failed check and related errors. -An uptime alert continuously monitors the configured URL with the criteria defined above. If a failure is detected, -a new [uptime issue](/product/issues/issue-details/uptime-issues/) with the failed check and related error details will be created. To avoid triggering false alerts due to transient issues like network glitches, new issues will only be created after a minimum of three consecutive failures have been detected, following the initial downtime detection. +To prevent false alerts caused by temporary network issues, **an issue is only generated after three consecutive failures** following the initial detection of downtime. Additionally, uptime checks are performed from a variety of geographical locations in a round-robin fashion. This ensures that each failed check comes from a different region, reducing the likelihood of false positives due to localized network failures. + +_In rare cases where Sentry is unable to perform a scheduled uptime check—such as during outages—the check status will be marked as "Unknown"._ + +## Notifications To start getting notifications for a new downtime issue, [configure an issue alert](/product/alerts/create-alerts/issue-alert-config/) and choose the issue category "uptime". Then choose how you'd like to be notified (via email, Slack, and so on). diff --git a/docs/product/alerts/uptime-monitoring/troubleshooting.mdx b/docs/product/alerts/uptime-monitoring/troubleshooting.mdx index 26b446512118a..779f09b21c107 100644 --- a/docs/product/alerts/uptime-monitoring/troubleshooting.mdx +++ b/docs/product/alerts/uptime-monitoring/troubleshooting.mdx @@ -4,8 +4,6 @@ sidebar_order: 53 description: "Learn how to troubleshoot potential Uptime Monitoring problems." --- - - ## Verify Firewall Configuration Some hosting platforms can block incoming requests from Sentry's Uptime Bot, falsely triggering uptime alerts. We recommend verifying your firewall configuration to ensure incoming requests from Sentry are allowed. diff --git a/docs/product/alerts/uptime-monitoring/uptime-tracing.mdx b/docs/product/alerts/uptime-monitoring/uptime-tracing.mdx index 8f48bfa059cf3..3342ebaa29fde 100644 --- a/docs/product/alerts/uptime-monitoring/uptime-tracing.mdx +++ b/docs/product/alerts/uptime-monitoring/uptime-tracing.mdx @@ -29,9 +29,8 @@ Error tracing is enabled by default for uptime checks. When downtime is detected Because uptime requests won't override your SDK’s error sampling rate, some errors may not appear in traces if that rate is set to below 1. -### Disabling Uptime Error Tracing - -To disable error tracing for uptime checks, configure a [before send](/platform-redirect/?next=/configuration/filtering/) filter in your SDK to ignore errors from Sentry's `User-Agent`. Here's an example: + + To disable error tracing for uptime checks, configure a [before send](/platform-redirect/?next=/configuration/filtering/) filter in your SDK to ignore errors from Sentry's `User-Agent`. Here's an example: ```typescript {tabTitle: Node.js Express} {filename: instrument.mjs} import * as Sentry from "@sentry/node"; @@ -53,6 +52,8 @@ Sentry.init({ }); ``` + + ## Tracing Spans Unlike error tracing, span tracing is **disabled** by default for uptime checks, but can be enabled by allowing sampling in your Uptime Alert settings. Enabling span tracing can be helpful because it provides a detailed view of the timing and flow of requests and operations during uptime checks, which is especially useful for diagnosing timeouts or performance issues. @@ -94,4 +95,4 @@ Sentry.init({ ## Billing Considerations - Errors and spans captured during uptime checks are [billed as regular events](https://sentry.io/pricing/) in Sentry. Configure sampling thoughtfully to manage costs. +Errors and spans captured during uptime checks are [billed as regular events](https://sentry.io/pricing/) in Sentry. Configure sampling thoughtfully to manage costs. diff --git a/docs/product/index.mdx b/docs/product/index.mdx index ffc34c82904db..cb04880b166aa 100644 --- a/docs/product/index.mdx +++ b/docs/product/index.mdx @@ -1,7 +1,7 @@ --- title: Product Walkthroughs sidebar_order: 30 -description: "Sentry can be used to not just observe, but debug errors as well as identify performance issues. Check out our product walkthroughs to see it in action." +description: "Sentry can be used to not just observe, but debug errors as well as identify performance issues. Check out our product walkthroughs to see it in action." --- ## What's Sentry? @@ -39,7 +39,6 @@ Our performance monitoring feature helps you track application performance, meas - Sentry helps you discover and act on [**trends**](/product/performance/trends/) before they become a bigger problem by surfacing transactions whose performance has changed significantly over time. - Sentry provides insights to help you monitor your app's performance. This includes web vitals, mobile vitals, queries, HTTP requests, and more. You can drill into event samples to investigate variations in performance. - ### Release Health Monitoring Giving Sentry visibility into your [**releases**](/product/releases/) makes it possible to see the moment a release starts to degrade so you can quickly take action. You get real-time visibility across your releases, allowing you to see core metrics like crash-free sessions, version adoption, and failure rate. @@ -50,6 +49,10 @@ Releases are integrated with the rest of Sentry so you can directly see how an e Our [**LLM Monitoring**](/product/insights/llm-monitoring/) feature gives you insights into your AI pipelines within the broader context of your app. When you `pip install sentry` into a project that's also using an AI provider like OpenAI, Sentry will automatically pick up useful metrics like token usage, prompts, and model IDs, and send them to our LLM Monitoring dashboard. +### Uptime Monitoring + +Sentry's [**Uptime Monitoring**](/product/alerts/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/alerts/uptime-monitoring/uptime-tracing/), Sentry enables you to pinpoint any errors that occur during an uptime check, simplifying triage and accelerating root cause analysis. + ### 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. diff --git a/docs/product/issues/issue-details/uptime-issues/index.mdx b/docs/product/issues/issue-details/uptime-issues/index.mdx index f72b6d5b32127..2e7e6d6f22ecf 100644 --- a/docs/product/issues/issue-details/uptime-issues/index.mdx +++ b/docs/product/issues/issue-details/uptime-issues/index.mdx @@ -4,8 +4,6 @@ sidebar_order: 40 description: "Learn how to use the information on the Issue Details page to debug an error issue." --- - - 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/alerts/uptime-monitoring/#uptime-check-criteria). diff --git a/includes/feature-stage-beta-uptime.mdx b/includes/feature-stage-beta-uptime.mdx deleted file mode 100644 index 18e61f42c2bac..0000000000000 --- a/includes/feature-stage-beta-uptime.mdx +++ /dev/null @@ -1,6 +0,0 @@ - - -Sentry Uptime Monitoring is currently in open beta, so be gentle - features are still in-progress and may have bugs. We recognize the irony. -For any questions or feedback, you can reach us on [GitHub Discussions](https://github.com/getsentry/sentry/discussions/78100). - -