diff --git a/docs/product/alerts/index.mdx b/docs/product/alerts/index.mdx index cc7ddf2cd8852..4db2b6e31f722 100644 --- a/docs/product/alerts/index.mdx +++ b/docs/product/alerts/index.mdx @@ -36,11 +36,11 @@ Create alerts to monitor metrics, such as: You can find a full list of available metric alerts in [Metric Alerts](/product/alerts/alert-types/#metric-alerts). -## Uptime Alerts +## Uptime Monitoring Alerts [Uptime alerts](/product/alerts/uptime-monitoring/) are triggered when an uptime HTTP check request fails to meet our [uptime check criteria](/product/alerts/uptime-monitoring/#uptime-check-criteria). -Use uptime alerts to ensure a specific URL is constantly available, even during periods of low or no traffic. +You can use uptime alerts to make sure a specific URL is constantly available, even during periods of low or no traffic. ## Creating Alerts diff --git a/docs/product/alerts/uptime-monitoring/automatic-detection.mdx b/docs/product/alerts/uptime-monitoring/automatic-detection.mdx index 470d67741baea..0b68e27690dc1 100644 --- a/docs/product/alerts/uptime-monitoring/automatic-detection.mdx +++ b/docs/product/alerts/uptime-monitoring/automatic-detection.mdx @@ -12,25 +12,16 @@ enhancing the reliability and availability of your web services. ## How It Works -We analyze all URLs detected in your project's captured error data, finding the most frequently seen hostnames. -For the most frequently seen hostname, an uptime alert is created if it passes our -[uptime check criteria](/product/alerts/uptime-monitoring/#uptime-check-criteria). +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 flaky alerts from being created, 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 at least three times, the hostname is dropped and re-evaluated after seven days. -Sentry will execute uptime checks against the hostname root path of the most frequently seen URLs. Example, if the - most seen URL in your events is `GET https://www.example.com/docs/introduction` the check will be made as `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 seen URL in your events is `GET https://www.example.com/docs/introduction` the check will be `GET https://www.example.com/`. ## Disabling Automatic Detection - -Automatically created uptime alerts can be deleted. Deleting an alert will disable automatic detection for the -entire project linked to the host. This feature can be turned off globally for the entire organization in the -[organization settings](https://sentry.io/orgredirect/organizations/:orgslug/settings/organization) page. +Deleting an alert will disable automatic detection for the entire project linked to the host. This feature can also be turned off globally for the entire organization from the [organization settings](https://sentry.io/orgredirect/organizations/:orgslug/settings/organization) page. Alternatively, the hostname's `robots.txt` can be updated to disallow Sentry: @@ -41,5 +32,5 @@ Disallow: * ## Current Limitations -Automatically detected uptime alerts cannot be edited at this time; they can only be deleted. Support for editing -will be added in the future. Additionally, each organization is limited to one automatically detected host. +In the current version, automatically-detected uptime alerts can only be deleted, not edited. Support for editing +will be added in the future. Additionally, each organization is limited to one automatically-detected host. diff --git a/docs/product/alerts/uptime-monitoring/index.mdx b/docs/product/alerts/uptime-monitoring/index.mdx index 5e3e09529e1f0..3bd4d26bd41eb 100644 --- a/docs/product/alerts/uptime-monitoring/index.mdx +++ b/docs/product/alerts/uptime-monitoring/index.mdx @@ -1,16 +1,13 @@ --- title: Uptime Monitoring sidebar_order: 50 -description: "Learn how Sentry monitors relevant URLs to help maintain uptime for your web services." +description: "Learn how to help maintain uptime for your web services by monitoring relevant URLs with Sentry's Uptime Monitoring." --- -Sentry's Uptime Monitoring allows you to ensure the availability and reliability of your web services effortlessly. -Currently, uptime is -[automatically configured](/product/alerts/uptime-monitoring/automatic-detection/) as a new -alert for 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. +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. ## Uptime Check Criteria @@ -20,11 +17,7 @@ For a URL to be considered up and running, the response must meet the following 1. **Successful Response (2xx Status Codes):** 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):** URLs returning an HTTP status code in the 300–399 range, -indicating a redirect, -will trigger Sentry to automatically follow the redirect -and verify the final destination URL returns a successful response. -This ensures that redirects don’t falsely trigger downtime alerts. +2. **Automatic Handling of Redirects (3xx Status Codes):** URLs returning an HTTP status code in the 300–399, indicating a redirect, will trigger Sentry to automatically follow the redirect 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. @@ -34,15 +27,10 @@ allowing you to address the underlying connectivity problems. ## Notifications -An existing uptime alert continuously monitors the configured URL with the criteria defined above, -and upon any failures, -a new [uptime issue](/product/issues/issue-details/uptime-issues/) is created with details of 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 failed check and related errors details will be created. -To receive notifications for a new downtime issue, -[configure an issue alert](/product/alerts/create-alerts/issue-alert-config/) -that matches the issue's category as "uptime" -with the chosen actions -(such as sending an email, triggering Slack, etc.). +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). [TODO: Add image of issue alert conditions here] diff --git a/docs/product/alerts/uptime-monitoring/troubleshooting.mdx b/docs/product/alerts/uptime-monitoring/troubleshooting.mdx index 32c5529259916..91d8202078b09 100644 --- a/docs/product/alerts/uptime-monitoring/troubleshooting.mdx +++ b/docs/product/alerts/uptime-monitoring/troubleshooting.mdx @@ -1,22 +1,20 @@ --- title: Troubleshooting sidebar_order: 52 -description: "Troubleshooting for Uptime Monitoring." +description: "Learn how to troubleshoot potential Uptime Monitoring problems." --- ## Verify Feature Eligibility -Uptime alerts are only available for organizations with early adopter features enabled, and that have relevant URLs -matching our [auto detection criteria](/product/alerts/uptime-monitoring/automatic-detection/#how-it-works). -Currently, organizations are limited to a single uptime alert. +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 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. -If you need to configure your firewall allowlist to include Sentry's Uptime Bot, we recommend checking against our `User-Agent` given our IP addresses can change without notice. +If you need to configure your firewall allowlist to include Sentry's Uptime Bot, we recommend checking against our `User-Agent`, given that our IP addresses can change without notice. ### User Agent @@ -26,10 +24,10 @@ Our uptime check requests use the following `User-Agent`: Mozilla/5.0 (compatible; SentryUptimeBot/1.0; +http://docs.sentry.io/product/alerts/uptime-monitoring/) ``` -### IP addresses +### IP Addresses See [IP Ranges](/security-legal-pii/security/ip-ranges/#uptime-monitoring) for a complete list of IP addresses used for uptime checks. -## Verify Issue Alerts Match Downtime Issues +## Verify That Issue Alerts Match Downtime Issues -Uptime alerts create downtime issues, if you are not receiving notifications when downtimes are detected, make sure you have properly [configured an issue alert](/product/alerts/create-alerts/issue-alert-config/) that matches the issue's category as "uptime". +Uptime alerts create downtime issues. If you're not receiving notifications when downtimes are detected, make sure you've properly [configured an issue alert](/product/alerts/create-alerts/issue-alert-config/) with the issue category "uptime". diff --git a/docs/product/issues/issue-details/uptime-issues/index.mdx b/docs/product/issues/issue-details/uptime-issues/index.mdx index b1b39cfa41a68..d671dbadb5ea3 100644 --- a/docs/product/issues/issue-details/uptime-issues/index.mdx +++ b/docs/product/issues/issue-details/uptime-issues/index.mdx @@ -14,14 +14,9 @@ active uptime alerts when HTTP requests fail to meet our ## Traced Errors -Uptime checks made against web services configured with one of Sentry's supported SDKs contains a -[trace](/concepts/key-terms/tracing/) that can be used to track detected errors from failed HTTP uptime checks. -The trace navigator allows you to browse through potential root causes of your downtime, providing a powerful tool -to quickly identify and resolve issues. +Uptime checks made against web services configured with one of Sentry's supported SDKs contain a +[trace](/concepts/key-terms/tracing/) that can be used to track detected errors resulting from failed HTTP uptime checks. The trace navigator allows you to browse through potential root causes of your downtime and is a powerful tool for quickly identifying and resolving issues. ## 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/alerts/uptime-monitoring/#uptime-check-criteria). If the URL experiences subsequent downtimes, -the issue's status changes 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/alerts/uptime-monitoring/#uptime-check-criteria). If the URL experiences subsequent downtime, the issue's status will change to regressed.