You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* added uptime monitors and clarified crons
* removing beta text from doc
* correcting pricing for uptime monitors
* Adding uptime to data storage locations
* removing beta text and clarifying automatic instrumentation
* Clarifications on deactivation note
Co-authored-by: Alex Krawiec <[email protected]>
* Add cautionary note about sensitive data in HTTP headers for uptime checks
* Add warning about uptime monitoring data storage locations
* Remove beta stage references from uptime monitoring documentation
* Add uptime checks to unsupported data relocation documentation
* Add uptime checks to the list of data stored in both US and EU locations
* Uptime product updates (#12579)
* Remove uptime monitoring section from early adopter features documentation
* Move disable uptime error tracing to an expandable
* add more info on uptime alert details page
* fix typo in Alert Details description for uptime checks
* Enhance uptime monitoring documentation with detailed failure criteria and notification setup
* add reference to multi-region uptime monitoring support
* Refine uptime alert configuration documentation for clarity and detail
* Add Uptime Monitoring section to product documentation
* Update docs/product/alerts/create-alerts/uptime-alert-config.mdx
Co-authored-by: Alex Krawiec <[email protected]>
* Update docs/product/index.mdx
Co-authored-by: Alex Krawiec <[email protected]>
---------
Co-authored-by: Alex Krawiec <[email protected]>
Co-authored-by: Gabriel Lopes <[email protected]>
Co-authored-by: Gabriel Lopes <[email protected]>
Copy file name to clipboardExpand all lines: docs/organization/data-storage-location/index.mdx
+13
Original file line number
Diff line number
Diff line change
@@ -55,6 +55,18 @@ Here’s a list of the types of data that may be stored in the US.
55
55
56
56
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.
57
57
58
+
### Data Stored in All Locations (US and EU)
59
+
60
+
Here’s a list of the types of data that will be stored in both data storage location (US and EU).
61
+
62
+
- Uptime checks
63
+
64
+
<Alerttitle="Uptime Monitoring"level="warning">
65
+
66
+
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.
67
+
68
+
</Alert>
69
+
58
70
## Using Data Storage Location APIs
59
71
60
72
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
Copy file name to clipboardExpand all lines: docs/pricing/index.mdx
+47-9
Original file line number
Diff line number
Diff line change
@@ -76,15 +76,15 @@ Tracing is enabled by and will be billed for in spans.
76
76
77
77
#### Cron Monitors Pricing
78
78
79
-
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.
79
+
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.
80
80
81
81
**Key Points:**
82
82
83
-
-**Deactivating or Deleting Monitors**:
83
+
-**Deactivating or Deleting Cron Monitors**:
84
84
- 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.
85
85
- Their quota becomes **reusable** within the **same billing period**.
86
-
-**Activating Monitors**:
87
-
- Sentry first uses any **reusable quota** from monitors deactivated or deleted in the current billing period.
86
+
-**Activating Cron Monitors**:
87
+
- Sentry first uses any **reusable quota** from cron monitors deactivated or deleted in the current billing period.
88
88
- If none is available, your **reserved quota** or **PAYG budget** is used.
89
89
90
90
<Alert>
@@ -93,23 +93,61 @@ All Sentry plans include **one cron monitor**. To activate additional monitors,
93
93
94
94
-**Quota Reuse Limitations**:
95
95
- Only available **within the same billing period**.
96
-
- Applies to monitors that were previously active and billed.
96
+
- Applies to cron monitors that were previously active and billed.
97
97
-**Reusable Quota Does Not Carry Over**:
98
98
- Reusable quota **does not carry over** to new billing periods.
99
99
100
100
</Alert>
101
101
102
-
**Monitors Across Billing Periods:**
102
+
**Cron Monitors Across Billing Periods:**
103
103
104
-
-Monitors remain active across billing periods if you have sufficient **reserved quota** or **PAYG budget**.
105
-
-Monitors may be automatically deactivated if there's insufficient budget.
106
-
-Monitors that have been manually deactivated or deleted remain in that state.
104
+
-Cron monitors remain active across billing periods if you have sufficient **reserved quota** or **PAYG budget**.
105
+
-Cron monitors may be automatically deactivated if there's insufficient budget.
106
+
-Cron monitors that have been manually deactivated or deleted remain in that state.
107
107
108
108
109
109
| Team PAYG | Business PAYG |
110
110
| ---------- | -------------- |
111
111
| $0.7800000 | $0.7800000 |
112
112
113
+
#### Uptime Monitors Pricing
114
+
115
+
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.
116
+
117
+
**Key Points:**
118
+
119
+
-**Deactivating or Deleting Uptime Monitors**:
120
+
- Deactivated or deleted uptime monitors will **count** towards your billing quota only if they were previously active in the current billing period.
121
+
- Their quota becomes **reusable** within the **same billing period**.
122
+
-**Activating Uptime Monitors**:
123
+
- Sentry first uses any **reusable quota** from uptime monitors deactivated or deleted in the current billing period.
124
+
- If none is available, your **reserved quota** or **PAYG budget** is used.
125
+
126
+
<Alert>
127
+
128
+
**Important:**
129
+
130
+
-**Quota Reuse Limitations**:
131
+
- Only available **within the same billing period**.
132
+
- Applies to uptime monitors that were previously active and billed.
133
+
-**Reusable Quota Does Not Carry Over**:
134
+
- Reusable quota **does not carry over** to new billing periods.
135
+
136
+
</Alert>
137
+
138
+
**Uptime Monitors Across Billing Periods:**
139
+
140
+
- Uptime monitors remain active across billing periods if you have sufficient **reserved quota** or **PAYG budget**.
141
+
- Uptime monitors may be automatically deactivated if there's insufficient budget.
142
+
- Uptime monitors that have been manually deactivated or deleted remain in that state.
143
+
144
+
145
+
| Team PAYG | Business PAYG |
146
+
| ---------- | -------------- |
147
+
| $1.00 | $1.00 |
148
+
149
+
150
+
113
151
#### Attachments Pricing (per GB)
114
152
115
153
| Attachment Size | Team Reserved | Team PAYG | Business Reserved | Business PAYG |
Copy file name to clipboardExpand all lines: docs/product/alerts/alert-types.mdx
+3-4
Original file line number
Diff line number
Diff line change
@@ -116,14 +116,13 @@ The **Alert Details** page also includes a list of suspect issues or transaction
116
116
117
117
## Uptime Alerts
118
118
119
-
<Includename="feature-stage-beta-uptime.mdx" />
120
-
121
119
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.
122
120
121
+
### Alert Details
123
122
124
-
### Alert Details Page
123
+
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.
125
124
126
-
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.
125
+
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.
Copy file name to clipboardExpand all lines: docs/product/alerts/create-alerts/uptime-alert-config.mdx
+24-13
Original file line number
Diff line number
Diff line change
@@ -4,42 +4,53 @@ sidebar_order: 30
4
4
description: "Learn more about the options for configuring an uptime alert."
5
5
---
6
6
7
-
<Includename="feature-stage-beta-uptime.mdx" />
8
-
9
7
Sentry provides several configuration options for creating an uptime alert based on your organization's needs as explained below.
10
8
11
9
## 1. Environment
12
10
13
11
First, specify which <PlatformLinkto="/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.
14
12
15
-
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).
13
+
The “Environment” dropdown lists the same environments available in your project, excluding hidden ones.
16
14
17
15
## 2. Project
18
16
19
-
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.
17
+
Specify the project associated with your alert rule. Any [uptime issues](/product/issues/issue-details/uptime-issues/)created will appear under this project.
20
18
21
19
## 3. Request Configuration
22
20
23
-
Configure how Sentry should execute an HTTP uptime check, by specifying:
-**URL**: The URL for which Sentry should execute an uptime check request.
26
-
-**Method**: The request method used to execute the uptime check. Available options are `GET`, `POST`, `HEAD`, `PUT`, `DELETE`, `PATCH`, and `OPTIONS`.
27
-
-**Headers**: The request headers included in the uptime check request.
28
-
-**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`.)
29
-
-**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.
23
+
Configure how Sentry performs HTTP uptime checks by setting the following options:
30
24
31
-
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`.
25
+
-**Interval**: The time between each uptime check. Options: `1 minute`, `5 minutes`, `10 minutes`, `20 minutes`, `30 minutes`, and `1 hour`.
26
+
-**Timeout**: The maximum time Sentry waits for a response before considering the request a failure (up to 30 seconds).
27
+
-**URL**: The target URL for the uptime check.
28
+
-**Method**: The HTTP method used (`GET`, `POST`, `HEAD`, `PUT`, `DELETE`, `PATCH`, or `OPTIONS`).
29
+
-**Headers**: Custom headers included in the request.
30
+
-**Body**: The request payload, available for `POST`, `PUT`, and `PATCH` methods.
31
+
-**Allow Sampling**: Enables span sampling for requests via the Sentry SDK. See [distributed tracing with uptime](/product/alerts/uptime-monitoring/uptime-tracing/) for details.
32
32
33
33
<Alertlevel="warning">
34
34
35
-
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).
35
+
When adding HTTP headers, be cautious of including sensitive data, such as API tokens or personal information, to prevent unintended exposure or storage.
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.
42
+
43
+
Additional notes:
44
+
45
+
- Include a `Content-Type` header if required by the target URL. For example, a JSON payload should have `Content-Type: application/json`.
46
+
- 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).
47
+
- 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).
48
+
- Sentry Uptime Tracing automatically appends a sentry-trace header to outgoing requests for distributed tracing. [Learn more](/product/alerts/uptime-monitoring/uptime-tracing/).
49
+
39
50
## 4. Alert Name
40
51
41
52
Give your alert a descriptive name, for example, "Landing Page" or "Contact Page".
42
53
43
54
## 5. Ownership
44
55
45
-
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.
56
+
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.
Copy file name to clipboardExpand all lines: docs/product/alerts/uptime-monitoring/automatic-detection.mdx
+1-3
Original file line number
Diff line number
Diff line change
@@ -4,11 +4,9 @@ sidebar_order: 51
4
4
description: "Learn how automatic detection of uptime monitoring works."
5
5
---
6
6
7
-
<Includename="feature-stage-beta-uptime.mdx" />
8
-
9
7
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.
10
8
11
-
9
+
The automatic creation of Uptime Monitors only happens if there are no other existing uptime monitors configured.
12
10
13
11
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.
Copy file name to clipboardExpand all lines: docs/product/alerts/uptime-monitoring/index.mdx
+9-5
Original file line number
Diff line number
Diff line change
@@ -4,8 +4,6 @@ sidebar_order: 50
4
4
description: "Learn how to help maintain uptime for your web services by monitoring relevant URLs with Sentry's Uptime Monitoring."
5
5
---
6
6
7
-
<Includename="feature-stage-beta-uptime.mdx" />
8
-
9
7
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.
10
8
11
9
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
30
28
If a DNS issue is detected, the check will be marked as a failure,
31
29
allowing you to address the underlying connectivity problems.
32
30
33
-
## Notifications
31
+
### Uptime Check Failures
32
+
33
+
An uptime alert continuously monitors the configured URL with the criteria defined above. If a failure occurs,
34
+
a new [uptime issue](/product/issues/issue-details/uptime-issues/) is created, including details about the failed check and related errors.
34
35
35
-
An uptime alert continuously monitors the configured URL with the criteria defined above. If a failure is detected,
36
-
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.
36
+
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.
37
+
38
+
_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"._
39
+
40
+
## Notifications
37
41
38
42
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).
Copy file name to clipboardExpand all lines: docs/product/alerts/uptime-monitoring/troubleshooting.mdx
-2
Original file line number
Diff line number
Diff line change
@@ -4,8 +4,6 @@ sidebar_order: 53
4
4
description: "Learn how to troubleshoot potential Uptime Monitoring problems."
5
5
---
6
6
7
-
<Includename="feature-stage-beta-uptime.mdx" />
8
-
9
7
## Verify Firewall Configuration
10
8
11
9
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.
Copy file name to clipboardExpand all lines: docs/product/alerts/uptime-monitoring/uptime-tracing.mdx
+5-4
Original file line number
Diff line number
Diff line change
@@ -29,9 +29,8 @@ Error tracing is enabled by default for uptime checks. When downtime is detected
29
29
30
30
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.
31
31
32
-
### Disabling Uptime Error Tracing
33
-
34
-
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:
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({
94
95
95
96
## Billing Considerations
96
97
97
-
Errors and spans captured during uptime checks are [billed as regular events](https://sentry.io/pricing/) in Sentry. Configure sampling thoughtfully to manage costs.
98
+
Errors and spans captured during uptime checks are [billed as regular events](https://sentry.io/pricing/) in Sentry. Configure sampling thoughtfully to manage costs.
0 commit comments