getsentry · mydea · Jan 28, 2025 · Jan 27, 2025 · Jan 27, 2025 · Jan 27, 2025
diff --git a/develop-docs/ingestion/relay/transaction-span-ratelimits.mdx b/develop-docs/ingestion/relay/transaction-span-ratelimits.mdx
@@ -69,19 +69,19 @@ Relay stage: customer managed, PoP-Relay or Processing-Relay. Until spans are ex
 should count the contained spans and generate an outcome with the contained span quantity + 1, for the segment span
 which would be generated from the transaction itself.
 
-<Note>
+<Alert>
 While it is desirable to have span counts correctly extracted from dropped transactions, it may not be feasible
 to do so at any stage of the processing pipeline. For example, it may not be possible to do so (malformed transactions)
 or simply too expensive to compute.
-</Note>
+</Alert>
 
 After spans have been extracted, the transaction is no longer a container of span items and just represents itself,
 thus, a dropped transaction with spans already extracted only generates outcomes for the total transactions and
 indexed transaction categories.
 
-<Note>
+<Alert>
 Span quotas are equivalent to transactions quotas, so all the above also applies for a span quota.
-</Note>
+</Alert>
 
 
 ## Examples

diff --git a/develop-docs/integrations/azuredevops/index.mdx b/develop-docs/integrations/azuredevops/index.mdx
@@ -25,12 +25,12 @@ When configuring the app, use the following values:
 | Supported account types         | Accounts in any organizational directory |
 | Redirect URI                    | `{YOUR_DOMAIN}/extensions/vsts/setup`                                                              |
 
-<Note>
+<Alert>
 
 Take note of your App ID as we'll need it later.
 ![App ID](./app-id.png)
 
-</Note>
+</Alert>
 
 Next go to Manager -> API Permissions to add the following permissions:
 * Azure DevOps (`vso.code`, `vso.graph`, `vso.work_item`, `vso.service_endpoint`)

diff --git a/develop-docs/sdk/data-model/event-payloads/lockreason.mdx b/develop-docs/sdk/data-model/event-payloads/lockreason.mdx
@@ -6,11 +6,11 @@ Represents an instance of a held lock (monitor object) in a thread. Typically, t
 to determine which other thread is holding the lock in case the current thread is blocked. In languages like
 `Java` or `Kotlin` this typically will be represented by a `java.lang.Object` type.
 
-<Note>
+<Alert>
 
 Lock reasons are always part of a [thread](/sdk/data-model/event-payloads/threads/). They cannot be declared as a top-level event property.
 
-</Note>
+</Alert>
 
 ## Attributes
 

diff --git a/develop-docs/sdk/platform-specifics/javascript-sdks/browser-tracing.mdx b/develop-docs/sdk/platform-specifics/javascript-sdks/browser-tracing.mdx
@@ -6,12 +6,12 @@ sidebar_order: 10
 
 The tracing behavior in our browser SDKs is somewhat unique and significantly differs from tracing in the backend. This page collects the most important aspects.
 
-<Note>
+<Alert>
   The aspects described in this document apply to all browser SDKs. This
   includes `@sentry/browser` and all SDKs building on top of it like
   `@sentry/react`, `@sentry/angular` or `@sentry/vue` but also the client-side
   parts of meta frameworks like `@sentry/nextjs`.
-</Note>
+</Alert>
 
 Please note that any kind of automatic tracing instrumentation in the browser requires the `browserTracingIntegration()` to be added to the SDK configuration.
 The default configuration of the SDK does not include any performance or tracing-related instrumentation to save on [bundle size](../bundle-size) for errors-only users.
@@ -103,13 +103,13 @@ There are sometimes discrepancies between the values we capture and the values t
 Generally speaking, most web vitals are accumulated while the pageload span is active and captured when we _end_ the pageload span. This works well for vitals that stabilize themselves very early in the lifecycle but
 it leads to discrepancies for vitals that are still changing after the pageload span ends. This is the case for `LCP` and `CLS` in particular.
 
-<Note>
+<Alert>
   At the time of writing, we're transitioning to a [more sophisticated `LCP` and
   `CLS` capturing
   technique](https://github.com/getsentry/sentry-javascript/issues/12714) that
   should improve the accuracy of these metrics. It will essentially work like
   `INP` collection works today.
-</Note>
+</Alert>
 
 ### Interaction To Next paint (INP)
 
@@ -134,13 +134,13 @@ This tracing model has a couple of consequences that are important to understand
 - **Quota Management**: Since the trace state does not change throughout a single page or route, the sampling decision of the initial span is carried over for all subsequent events. This means that the sampling decision is only made once per page or route and is not reevaluated for each event. Furthermore, subsequent http (`fetch` or `XmlHttpRequest`) also propagate this sampling decision to potential downstream services. This can lead to a higher number of events being sent to Sentry than before.
 - **Long-lived Traces**: Not every web application features navigations (hard or soft). For pages where users simply remain on one page without making navigations (e.g. a chat application), the trace id will remain constant for the entire duration of the user journey. This can lead to very long-lived traces that can potentially grow very large.
 
-<Note>
+<Alert>
 
 As outlined above, some of the consequences have negative product or UX implications.
 This is a known issue and we're working on an update to the trace lifetime model to address these issues.
 However, this is a complex topic and we're still in the process of evaluating the best solution.
 
-</Note>
+</Alert>
 
 ## Trace Propagation
 

diff --git a/develop-docs/sdk/telemetry/check-ins.mdx b/develop-docs/sdk/telemetry/check-ins.mdx
@@ -135,10 +135,10 @@ result in a poor DX.
 
 ### Schedule configuration
 
-<Note>
+<Alert>
 This configuration format differs slightly from what is accepted in the
 monitors frontend APIs.
-</Note>
+</Alert>
 
 `type`
 

diff --git a/develop-docs/sdk/telemetry/sessions/index.mdx b/develop-docs/sdk/telemetry/sessions/index.mdx
@@ -3,11 +3,11 @@ title: Sessions
 sidebar_order: 6
 ---
 
-<Note>
+<Alert>
 
 Looking for Sentry's **Session Replay**? Click <a class href="https://docs.sentry.io/product/session-replay/">here</a> to learn more.
 
-</Note>
+</Alert>
 
 For basic health tracking Sentry accepts <Link to="/sdk/data-model/envelopes/">envelopes</Link>
 containing session update events. These session update events can be used to

diff --git a/develop-docs/sdk/telemetry/traces/index.mdx b/develop-docs/sdk/telemetry/traces/index.mdx
@@ -14,11 +14,11 @@ Reference implementations:
 - [JavaScript SDK](https://github.com/getsentry/sentry-javascript/tree/master/packages/core/src/tracing)
 - [Python SDK](https://github.com/getsentry/sentry-python/blob/master/sentry_sdk/tracing.py)
 
-<Note>
+<Alert>
 
 This document uses standard interval notation, where `[` and `]` indicates closed intervals, which include the endpoints of the interval, while `(` and `)` indicates open intervals, which exclude the endpoints of the interval. An interval `[x, y)` covers all values starting from `x` up to but excluding `y`.
 
-</Note>
+</Alert>
 
 ## SDK Configuration
 

diff --git a/docs/account/user-settings/index.mdx b/docs/account/user-settings/index.mdx
@@ -14,11 +14,11 @@ Security Settings include options to reset a password, sign out of all devices,
 
 After setting up your two-factor authentication codes, click "View Codes" to download, print, or copy your codes to a secure location. If you cannot receive two-factor authentication codes in the future, such as if you lose your device, use your recovery codes to access your account.
 
-<Note>
+<Alert>
 
 Clicking "Sign out of all devices" will end your sessions with any device logged in to Sentry using your account.
 
-</Note>
+</Alert>
 
 ## Notifications
 

diff --git a/docs/api/auth.mdx b/docs/api/auth.mdx
@@ -51,8 +51,8 @@ As an example, to get information about the project which your key is bound to,
 curl -u {API_KEY}: https://sentry.io/api/0/organizations/{organization_slug}/projects/
 ```
 
-<Note>
+<Alert>
 
 You **must** pass a value for the password, which is the reason the `:` is present in our example.
 
-</Note>
+</Alert>
diff --git a/docs/api/ratelimits.mdx b/docs/api/ratelimits.mdx
@@ -32,8 +32,8 @@ Every API request response includes the following headers:
 
 The rate limiter looks at the caller's identity instead of the bearer token or cookie. As such, the rate limit cannot be bypassed by generating multiple tokens.
 
-<Note>
+<Alert>
 
 Polling the API for updates is likely to quickly trigger rate limiting. We recommend using our [webhooks](/organization/integrations/integration-platform/webhooks/), if possible.
 
-</Note>
+</Alert>
diff --git a/docs/cli/configuration.mdx b/docs/cli/configuration.mdx
@@ -26,9 +26,9 @@ You can manually create an [Organization Auth Token](https://sentry.io/orgredire
 
 You can also sign in to your Sentry account (if you're not already) and create an Auth Token directly from this page.
 
-<Note>
+<Alert>
 Some CLI functionality, such as [Crons Monitoring](/product/crons/getting-started/cli/), is dependent on DSN authentication.
-</Note>
+</Alert>
 
 You can create an Auth Token from this page in one of the following three ways:
 
@@ -112,7 +112,7 @@ The header that will be added to every outgoing request in `key:value` format.
 
 `SENTRY_ALLOW_FAILURE`
 
-Note: This option will ignore the CLI's failure when uploading symbols. **BE AWARE** this will unblock your CI in case Sentry has issues, but you won't have unminified/unsymbolicated crashes in production. 
+Note: This option will ignore the CLI's failure when uploading symbols. **BE AWARE** this will unblock your CI in case Sentry has issues, but you won't have unminified/unsymbolicated crashes in production.
 When using this flag, you should download your sourcemaps/debug files from CI, to re-run the upload symbols command at a later point once Sentry is available.
 
 (_http.keepalive_):

diff --git a/docs/cli/installation.mdx b/docs/cli/installation.mdx
@@ -61,11 +61,11 @@ In case you want to install this with npm system wide with sudo you will need to
 sudo npm install -g @sentry/cli --unsafe-perm
 ```
 
-<Note>
+<Alert>
 
 This installation is not recommended however.
 
-</Note>
+</Alert>
 
 ### Downloading From a Custom Source
 

diff --git a/docs/cli/releases.mdx b/docs/cli/releases.mdx
@@ -6,11 +6,11 @@ description: "Sentry's command line interface can be used for release management
 
 The `sentry-cli` tool can be used for release management on Sentry. It allows you to create, edit and delete releases as well as upload release artifacts for them. Note that releases are global per organization. If you want the releases in different projects to be treated as separate entities, make the version name unique across the organization. For example, if you have projectA and projectB that share version numbers, you can name the releases `projectA-1.0` and `projectB-1.0` respectively.
 
-<Note>
+<Alert>
 
 Because releases work on projects you will need to specify the organization and project you are working with. For more information about this refer to [Working with Projects](/cli/configuration/#sentry-cli-working-with-projects).
 
-</Note>
+</Alert>
 
 ## Creating Releases
 

diff --git a/docs/concepts/data-management/event-grouping/index.mdx b/docs/concepts/data-management/event-grouping/index.mdx
@@ -70,11 +70,11 @@ You can customize error grouping using a combination of the following options, l
 1. In your SDK, using [SDK Fingerprinting](/platform-redirect/?next=/usage/sdk-fingerprinting/)
    > Sets a new fingerprint for incoming events based on matchers in the SDK. This doesn't affect already existing issues. Note that is not supported in WebAssembly.
 
-<Note>
+<Alert>
 
 Stack trace rules can work as a combination of both SDK and project settings. As a result, we maintain the documentation in one location.
 
-</Note>
+</Alert>
 
 ## How to View the Fingerprint
 

diff --git a/docs/concepts/data-management/event-grouping/stack-trace-rules.mdx b/docs/concepts/data-management/event-grouping/stack-trace-rules.mdx
@@ -8,22 +8,22 @@ description: "Learn how to use stack trace rules to group incoming events based
 
 Stack trace rules improve issue tracking by ensuring accurate grouping and better classification of stack frames as in-app or system. This helps focus on relevant code, reduces noise, and minimizes false positives. By tailoring rules to your project, you can streamline debugging and maintain consistency across teams or multiple applications.
 
-When you set stack trace rules (previously known as _grouping enhancements_) for grouping in Sentry, they influence the data that's fed into the grouping algorithm. These rules can be configured on a per-project basis by going to your project settings and then clicking on "Issue Grouping". 
+When you set stack trace rules (previously known as _grouping enhancements_) for grouping in Sentry, they influence the data that's fed into the grouping algorithm. These rules can be configured on a per-project basis by going to your project settings and then clicking on "Issue Grouping".
 
 Here are a few things to note about stack trace rules:
 
 - Each rule is written on a single line.
 - Rules consist of one or more match expressions followed by one or more actions triggered when all expressions match.
 - Rules are applied sequentially, from top to bottom, across all frames in the stack trace.
 
-In addition, the stack trace rules using the below matchers and actions can also be applied to incoming profiles to improve frame classification (in-app vs system, for example). 
+In addition, the stack trace rules using the below matchers and actions can also be applied to incoming profiles to improve frame classification (in-app vs system, for example).
 
 Allowed Matchers:
   * `stack.abs_path`
   * `stack.module`
   * `stack.function`
   * `stack.package`
-  
+
 Allowed Actions:
   * `+app`
   * `-app`
@@ -235,11 +235,11 @@ stack.function:std::*    -app
 stack.function:boost::*  -app
 ```
 
-<Note>
+<Alert>
 
 You need to force all frames to be in-app first because there might already have been some defaults set by the client SDK or earlier processing.
 
-</Note>
+</Alert>
 
 If you're using the `sentry-cocoa` SDK, you can also achieve the same result by marking other frames `not inApp`. The following sample marks functions from the classes `DataRequest` and `DownloadRequest` as `not inApp`.
 

diff --git a/docs/concepts/key-terms/dsn-explainer.mdx b/docs/concepts/key-terms/dsn-explainer.mdx
@@ -48,8 +48,8 @@ Has the following settings:
 - Public Key = public
 - Project ID = 1
 
-<Note>
+<Alert>
 
 The secret part of the DSN is optional and effectively deprecated. While clients will still honor it, if supplied, future versions of Sentry will entirely ignore it.
 
-</Note>
+</Alert>
diff --git a/docs/concepts/key-terms/sample-rates.mdx b/docs/concepts/key-terms/sample-rates.mdx
@@ -23,9 +23,9 @@ Choose a sampling rate that balances data accuracy with performance and storage
 
 ## Sampling Rate Options
 
-<Note>
+<Alert>
 Some of the options below aren't available in every SDK; check out our platform-specific docs for more info.
-</Note>
+</Alert>
 
 ### Error Events
 

diff --git a/docs/concepts/key-terms/tracing/distributed-tracing.mdx b/docs/concepts/key-terms/tracing/distributed-tracing.mdx
@@ -4,7 +4,7 @@ sidebar_order: 10
 description: With distributed tracing, you can track software performance and measure throughput & latency, while seeing the impact of errors across multiple systems.
 ---
 
-Distributed tracing provides a connected view of your application from frontend to backend. It helps track software performance, measure [metrics](/product/performance/metrics/) like throughput and latency, and display the impact of errors across multiple systems. This makes Sentry a more complete [performance monitoring](/product/performance/) solution, aiding in diagnosing problems and measuring your application's overall health. 
+Distributed tracing provides a connected view of your application from frontend to backend. It helps track software performance, measure [metrics](/product/performance/metrics/) like throughput and latency, and display the impact of errors across multiple systems. This makes Sentry a more complete [performance monitoring](/product/performance/) solution, aiding in diagnosing problems and measuring your application's overall health.
 
 [Tracing](/concepts/key-terms/tracing/distributed-tracing/) in Sentry provides insights such as:
 
@@ -36,11 +36,11 @@ Transactions share most properties (start and end time, tags, and so on) with th
 Before the transaction is sent, the `tags` and `data` properties will get merged with data from the global scope. (Global scope data is set in `Sentry.init()` or by using `Sentry.configureScope()`, `Sentry.setTag()`, `Sentry.setUser()`, or `Sentry.setExtra()`.)
 
 
-<Note>
+<Alert>
 
 Transaction names can contain **sensitive data**. See [Scrubbing Sensitive Data](/platforms/javascript/data-management/sensitive-data/#scrubbing-data) for more information.
 
-</Note>
+</Alert>
 
 #### Spans
 

diff --git a/docs/concepts/search/index.mdx b/docs/concepts/search/index.mdx
@@ -8,9 +8,9 @@ Search is available on several features throughout [sentry.io](https://sentry.io
 
 ## Query Syntax
 
-<Note>
+<Alert>
 You'll only need to use query syntax if you're using a Sentry [API](/api/). You'll get pre-populated suggestions once you start typing in your search terms when using the search bar anywhere in [Sentry.io](https://sentry.sentry.io/).
-</Note>
+</Alert>
 
 Search queries are constructed using a `key:value` pattern, with an optional raw search at the end. Each `key:value` pair is a `token` and the optional raw search is itself a single `token`. The `key:value` pair `tokens` are treated as issue or event properties. The optional raw search is treated as a single `token` and searches event titles/messages.
 
@@ -52,11 +52,11 @@ Here are some examples of valid comparison operator searches:
 
 ### Using `OR` and `AND`
 
-<Note>
+<Alert>
 
 `OR` and `AND` search conditions are only available for [Discover](/product/explore/discover-queries/), [Performance](/product/performance/), and [Metric Alerts](/product/alerts-notifications/metric-alerts/).
 
-</Note>
+</Alert>
 
 Use `OR` and `AND` between tokens, and use parentheses `()` to group conditions. `AND` can also be used between non-aggregates and aggregates. However, `OR` cannot.
 

diff --git a/docs/concepts/search/searchable-properties/events.mdx b/docs/concepts/search/searchable-properties/events.mdx
@@ -14,11 +14,11 @@ You can search by event properties in the following [sentry.io](https://sentry.i
 - Issues - as indicated in the list below
 - Alerts - when creating a metric alert
 
-<Note>
+<Alert>
 
 Please note that in Alerts only a limited number of properties are available for [filtering transaction events](/product/alerts/create-alerts/metric-alert-config/#tags--properties).
 
-</Note>
+</Alert>
 
 When searching on event properties within the **Issues** page, the search will return any issue that has _one or more events_ matching the supplied event properties filter.
 

diff --git a/docs/concepts/search/searchable-properties/issues.mdx b/docs/concepts/search/searchable-properties/issues.mdx
@@ -10,9 +10,9 @@ sidebar_order: 10
 
 Below is a list of keys and tokens that can be used in the issues search.
 
-<Note>
+<Alert>
 You'll only need to use query syntax for **datetime** and **relative time** searchable property types if you're using the Sentry [API](/api/).
-</Note>
+</Alert>
 
 <DefinitionList>
 

diff --git a/docs/contributing/approach/product-docs/write-index.mdx b/docs/contributing/approach/product-docs/write-index.mdx
@@ -6,11 +6,11 @@ sidebar_order: 10
 
 This guide to writing index pages is just that—a guide. It won’t answer every question you have about how to write a good index page, but it will help you make a good start.
 
-<Note>
+<Alert>
 
 While we use the term “index page” to refer to the top-level page about a feature in Docs, we don’t use this terminology in the actual Docs. Learn more in [Other Guidelines](#other-guidelines).
 
-</Note>
+</Alert>
 
 The index page: