feat(uptime): add open beta documentation for uptime (#11420)

* feat(uptime): add open beta documentation for uptime * Apply suggestions from code review Co-authored-by: Liza Mock <[email protected]> * Apply suggestions from code review Co-authored-by: Liza Mock <[email protected]> * fix broken uptime issues links --------- Co-authored-by: Liza Mock <[email protected]>
getsentry · Sep 25, 2024 · 1ddc4cb · 1ddc4cb
1 parent 82692db
commit 1ddc4cb
Show file tree

Hide file tree

Showing 10 changed files with 95 additions and 40 deletions.
diff --git 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
 ![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
+
+<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 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
@@ -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).
    ![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
 
@@ -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
@@ -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
@@ -0,0 +1,44 @@
+---
+title: Uptime Alert Configuration
+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).
+
+## 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`.
+
+<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).
+
+</Alert>
+
+## 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
@@ -4,25 +4,23 @@ sidebar_order: 51
 description: "Learn how automatic detection of uptime monitoring works."
 ---
 
-<Include name="feature-stage-alpha-uptime.mdx" />
+<Include name="feature-stage-beta-uptime.mdx" />
 
-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.
 
 <Alert level="info">
-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/`.
 </Alert>
 
+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: *
 ```
 
 <Alert level="warning">
-**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.
 </Alert>
-
-## 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
@@ -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."
 ---
 
-<Include name="feature-stage-alpha-uptime.mdx" />
+<Include name="feature-stage-beta-uptime.mdx" />
 
-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
@@ -4,11 +4,7 @@ sidebar_order: 52
 description: "Learn how to troubleshoot potential Uptime Monitoring problems."
 ---
 
-<Include name="feature-stage-alpha-uptime.mdx" />
-
-## 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.
+<Include name="feature-stage-beta-uptime.mdx" />
 
 ## 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
@@ -4,7 +4,7 @@ sidebar_order: 40
 description: "Learn how to use the information on the Issue Details page to debug an error issue."
 ---
 
-<Include name="feature-stage-alpha-uptime.mdx" />
+<Include name="feature-stage-beta-uptime.mdx" />
 
 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
diff --git a/includes/feature-stage-beta-uptime.mdx b/includes/feature-stage-beta-uptime.mdx
@@ -0,0 +1,6 @@
+<Note>
+
+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 [[email protected]](mailto:[email protected]).
+
+</Note>