Uptime Monitoring Docs Updates

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
+
+<Alert title="Uptime Monitoring" level="warning">
+
+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.
+
+</Alert>
+
 ## 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

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/)

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.
 
 <Alert>
@@ -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.
 
 </Alert>
 
-**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.
+
+<Alert>
+
+**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.
+
+</Alert>
+
+**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 |

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
 
-<Include name="feature-stage-beta-uptime.mdx" />
-
 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
 

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."
 ---
 
-<Include name="feature-stage-beta-uptime.mdx" />
-
 Sentry provides several configuration options for creating an uptime alert based on your organization's needs as explained below.
 
 ## 1. Environment
 
 First, specify which <PlatformLink to="/configuration/environments/">environment</PlatformLink> 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.
 
 <Alert level="warning">
 
-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.
 
 </Alert>
 
+![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.

docs/product/alerts/uptime-monitoring/automatic-detection.mdx

@@ -4,11 +4,9 @@ sidebar_order: 51
 description: "Learn how automatic detection of uptime monitoring works."
 ---
 
-<Include name="feature-stage-beta-uptime.mdx" />
-
 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.
 

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."
 ---
 
-<Include name="feature-stage-beta-uptime.mdx" />
-
 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).
 

docs/product/alerts/uptime-monitoring/troubleshooting.mdx

@@ -4,8 +4,6 @@ sidebar_order: 53
 description: "Learn how to troubleshoot potential Uptime Monitoring problems."
 ---
 
-<Include name="feature-stage-beta-uptime.mdx" />
-
 ## 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.

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:
+<Expandable permalink title="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:
 
 ```typescript {tabTitle: Node.js Express} {filename: instrument.mjs}
 import * as Sentry from "@sentry/node";
@@ -53,6 +52,8 @@ Sentry.init({
 });
 ```
 
+</Expandable>
+
 ## 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.