diff --git a/docs/product/alerts/alert-types.mdx b/docs/product/alerts/alert-types.mdx
index 3b38b12b2c80e..71309a9b1130a 100644
--- a/docs/product/alerts/alert-types.mdx
+++ b/docs/product/alerts/alert-types.mdx
@@ -1,13 +1,14 @@
---
title: Alert Types
sidebar_order: 10
-description: "Learn about the two types of alerts Sentry provides: issue alerts and metric alerts."
+description: "Learn about the three types of alerts Sentry provides: issue alerts, metric alerts, and uptime monitoring alerts."
---
-You can create two types of alerts:
+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
@@ -112,3 +113,14 @@ The **Alert Details** page shows you the history of a metric alert rule for the
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/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 Page
+
+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.
diff --git a/docs/product/alerts/create-alerts/index.mdx b/docs/product/alerts/create-alerts/index.mdx
index 78f0856b77aae..9b8e7359e779c 100644
--- a/docs/product/alerts/create-alerts/index.mdx
+++ b/docs/product/alerts/create-alerts/index.mdx
@@ -13,13 +13,14 @@ The minimum role required to create alerts is member. Sentry users with manager
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), while selecting any other option creates a [metric alert](/product/alerts/alert-types/#metric-alerts).
+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).
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
@@ -30,4 +31,4 @@ You can also create an alert by duplicating an existing issue or metric alert ru
## 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.
+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/routing-alerts.mdx b/docs/product/alerts/create-alerts/routing-alerts.mdx
index b1d162eaa83f1..c5812c4a8e31a 100644
--- a/docs/product/alerts/create-alerts/routing-alerts.mdx
+++ b/docs/product/alerts/create-alerts/routing-alerts.mdx
@@ -1,6 +1,6 @@
---
title: Alert Routing With Integrations
-sidebar_order: 30
+sidebar_order: 40
description: "Learn more about routing alerts using Sentry integrations."
---
diff --git a/docs/product/alerts/create-alerts/uptime-alert-config.mdx b/docs/product/alerts/create-alerts/uptime-alert-config.mdx
new file mode 100644
index 0000000000000..a4a1bc1269944
--- /dev/null
+++ b/docs/product/alerts/create-alerts/uptime-alert-config.mdx
@@ -0,0 +1,44 @@
+---
+title: Uptime Alert Configuration
+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).
+
+## 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.
+
+## 3. Request Configuration
+
+Configure how Sentry should execute an HTTP uptime check, by specifying:
+
+- **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`.)
+
+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`.
+
+
+
+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).
+
+
+
+## 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.
diff --git a/docs/product/alerts/uptime-monitoring/automatic-detection.mdx b/docs/product/alerts/uptime-monitoring/automatic-detection.mdx
index 132799aad27d8..11d5929baf06b 100644
--- a/docs/product/alerts/uptime-monitoring/automatic-detection.mdx
+++ b/docs/product/alerts/uptime-monitoring/automatic-detection.mdx
@@ -4,25 +4,23 @@ sidebar_order: 51
description: "Learn how automatic detection of uptime monitoring works."
---
-
+
-The automatic detection of uptime alerts sets up uptime alerts for the most frequently encountered
-hostnames in all URLs of your error data. This helps ensure that critical hostnames are continuously monitored,
-enhancing the reliability and availability of your web services.
+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.
-## How It Works
-We analyze all the URLs detected in your project's captured error data to find the hostname that appears most frequently. We then create an uptime alert if it passes our [uptime check criteria](/product/alerts/uptime-monitoring/#uptime-check-criteria).
-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 at least three times, the hostname is dropped and re-evaluated after seven days.
+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.
-Sentry will execute uptime checks against the hostname root path of the most frequently seen URLs. For example, if the most seen URL in your events is `GET https://www.example.com/docs/introduction` the check will be `GET https://www.example.com/`.
+ Sentry will execute uptime checks against the hostname root path of the most frequently-seen URLs. For example, if the most frequently-seen URL in your events is `GET https://www.example.com/docs/introduction`, the check will be `GET https://www.example.com/`.
+Once an automatically detected uptime alert has been created, you'll be able to [customize its configuration](/product/alerts/create-alerts/uptime-alert-config/), including the HTTP request method, headers, and request body.
+
## Disabling Automatic Detection
-If you prefer not to use automatically detected uptime alerts, you have two options to disable them:
+If you prefer not to use automatically detected uptime alerts, you have two options for disabling them:
1. **Deleting Uptime Alerts:** You can directly delete existing automatically detected uptime alerts from your [Alerts page](https://sentry.io/orgredirect/organizations/:orgslug/alerts/rules). Once deleted, these alerts will not be re-created automatically in the future.
2. **Blocking Sentry via `robots.txt`:** Another method to prevent automatic detection is by updating your hostname's robots.txt file to block Sentry’s uptime monitoring bot. To do this, add the following lines to your robots.txt file:
@@ -33,9 +31,5 @@ Disallow: *
```
-**Note:** The `robots.txt` file will only prevent Sentry from detecting URLs that it encounters in the future. Existing URLs that have already been detected will continue to have uptime alerts unless they are manually deleted.
+**Note:** The `robots.txt` file only prevents Sentry from detecting URLs that it encounters after its been implemented. Existing URLs that have already been detected will continue to have uptime alerts unless they're manually deleted.
-
-## Current Limitations
-
-At present, automatically detected uptime alerts have limited editability. You cannot update the URLs associated with these alerts. Only the alert name and owner can be modified. The ability to edit URLs and other alert settings is planned for a future release. Additionally, each organization is limited to one automatically detected hostname.
diff --git a/docs/product/alerts/uptime-monitoring/index.mdx b/docs/product/alerts/uptime-monitoring/index.mdx
index 8fa5d56967f84..9708b1dacc0a8 100644
--- a/docs/product/alerts/uptime-monitoring/index.mdx
+++ b/docs/product/alerts/uptime-monitoring/index.mdx
@@ -4,31 +4,36 @@ 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.
-In the current version, uptime is [automatically configured](/product/alerts/uptime-monitoring/automatic-detection/) as a new alert for only the most relevant URL detected in your organization. In future updates, you'll have the flexibility to add and monitor additional URLs.
+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.
+
+## Set Up
+
+Uptime is [automatically configured](/product/alerts/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.
## Uptime Check Criteria
-Our uptime monitoring system verifies the availability of your URLs
-by performing GET requests at regular 5-minute intervals.
-For a URL to be considered up and running, the response must meet the following criteria:
+Our uptime monitoring system verifies the availability of your URLs by performing HTTP requests at regular, pre-configured intervals. For a URL to be considered up and running, the response must meet the following criteria:
1. **Successful Response (2xx Status Codes):**
-The URL must return an HTTP status code in the 200–299 range, indicating a successful request.
+ The URL must return an HTTP status code in the 200–299 range, indicating a successful request.
2. **Automatic Handling of Redirects (3xx Status Codes):** Sentry will follow redirects for URLs returning an HTTP status code in the 300–399 range and verify that the final destination URL returns a successful response. This ensures that redirects won't falsely trigger downtime alerts.
3. **Timeout Setting:** Each request has a timeout threshold of 10 seconds.
-If the server doesn't respond within this period, the check will be marked as a failure,
-indicating a potential downtime or performance issues.
+ If the server doesn't respond within this period, the check will be marked as a failure,
+ indicating a potential downtime or performance issues.
4. **DNS Issue Detection:** Our monitoring also includes the detection of DNS resolution issues.
-If a DNS issue is detected, the check will be marked as a failure,
-allowing you to address the underlying connectivity problems.
+ If a DNS issue is detected, the check will be marked as a failure,
+ allowing you to address the underlying connectivity problems.
## Notifications
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 failed check and related errors details will be created.
+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 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 77756eef4a5c3..ad3fa40361c68 100644
--- a/docs/product/alerts/uptime-monitoring/troubleshooting.mdx
+++ b/docs/product/alerts/uptime-monitoring/troubleshooting.mdx
@@ -4,11 +4,7 @@ sidebar_order: 52
description: "Learn how to troubleshoot potential Uptime Monitoring problems."
---
-
-
-## Verify Feature Eligibility
-
-Uptime alerts are only available for organizations that have early adopter features enabled. They must also have URLs that match our [auto detection criteria](/product/alerts/uptime-monitoring/automatic-detection/#how-it-works). In the current version, organizations are limited to a single uptime alert.
+
## Verify Firewall Configuration
diff --git a/docs/product/issues/issue-details/uptime-issues/index.mdx b/docs/product/issues/issue-details/uptime-issues/index.mdx
index 3d32276482d5d..f72b6d5b32127 100644
--- a/docs/product/issues/issue-details/uptime-issues/index.mdx
+++ b/docs/product/issues/issue-details/uptime-issues/index.mdx
@@ -4,7 +4,7 @@ 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
diff --git a/includes/feature-stage-alpha-uptime.mdx b/includes/feature-stage-alpha-uptime.mdx
deleted file mode 100644
index 087ada3a50776..0000000000000
--- a/includes/feature-stage-alpha-uptime.mdx
+++ /dev/null
@@ -1,3 +0,0 @@
-
- This feature is only available if your organization has enabled [early adopter features](/organization/early-adopter-features/). Early adopter features are still in-progress and may have bugs. We recognize the irony. If you’re interested in participating, enable early adopter features in [organization settings](https://sentry.io/orgredirect/organizations/:orgslug/settings/organization).
-
diff --git a/includes/feature-stage-beta-uptime.mdx b/includes/feature-stage-beta-uptime.mdx
new file mode 100644
index 0000000000000..3eb7e37582e4f
--- /dev/null
+++ b/includes/feature-stage-beta-uptime.mdx
@@ -0,0 +1,6 @@
+
+
+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 [Discord](https://discord.gg/sentry) or via email at [uptime-feedback@sentry.io](mailto:uptime-feedback@sentry.io).
+
+