diff --git a/develop-docs/backend/application-domains/transaction-clustering/index.mdx b/develop-docs/backend/application-domains/transaction-clustering/index.mdx
index 53f10211ec8d5..bcfcb49262826 100644
--- a/develop-docs/backend/application-domains/transaction-clustering/index.mdx
+++ b/develop-docs/backend/application-domains/transaction-clustering/index.mdx
@@ -23,7 +23,7 @@ and it falls back to the raw URL (or rather,
[its path component](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax)).
This makes it harder for the user to extract insights from [Performance
-metrics](https://docs.sentry.io/product/insights/overview/metrics/), because instead of presenting averages, percentiles and distributions of groups of transactions that logically
+metrics](https://docs.sentry.io/product/dashboards/sentry-dashboards/transaction-summary/#metrics-in-this-view), because instead of presenting averages, percentiles and distributions of groups of transactions that logically
belong together, we end up with a bunch of one-off transaction groups.
```URLs
diff --git a/docs/concepts/key-terms/tracing/distributed-tracing.mdx b/docs/concepts/key-terms/tracing/distributed-tracing.mdx
index 8c31212510365..72dc49d785fbd 100644
--- a/docs/concepts/key-terms/tracing/distributed-tracing.mdx
+++ b/docs/concepts/key-terms/tracing/distributed-tracing.mdx
@@ -8,7 +8,7 @@ description: >-
og_image: /og-images/concepts-key-terms-tracing-distributed-tracing.png
---
-Distributed tracing provides a connected view of your application from frontend to backend. It helps track software performance, measure [metrics](/product/insights/overview/metrics/) like throughput and latency, and display the impact of errors across multiple systems. This makes Sentry a more complete [performance monitoring](/product/insights/overview/) 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/dashboards/sentry-dashboards/transaction-summary/#metrics-in-this-view) like throughput and latency, and display the impact of errors across multiple systems. This makes Sentry a more complete [performance monitoring](/product/insights/overview/) 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:
@@ -23,7 +23,7 @@ A tracing tool focuses on what happened (and when), logging events during a prog
It's important to note that tracing is not [profiling](/product/explore/profiling/). A profiler measures various aspects of an application's operation, resulting in a statistical summary. While both diagnose application problems, they differ in what they measure and how data is recorded.
-Learn more in this [Tracing: Frontend issues with backend solutions](https://sentry.io/resources/tracing-frontend-issues-with-backend-solutions/?original_referrer=https%3A%2F%2Fblog.sentry.io%2F) workshop.
+Learn more in our [tracing documentation](/product/sentry-basics/tracing/).
### The Tracing Data Model
diff --git a/docs/concepts/search/index.mdx b/docs/concepts/search/index.mdx
index c997a23220042..c7d6c0936de73 100644
--- a/docs/concepts/search/index.mdx
+++ b/docs/concepts/search/index.mdx
@@ -164,9 +164,14 @@ browser:EndsWithchrome, !browser:EndsWithfire
Page filters allow you to narrow down the results shown on a page by selecting specific projects, environments, and date ranges. After you've set your filters, they'll persist as you navigate across pages in Sentry.
+### Dashboard Page Filters
+Dashboard page filters allow you to narrow down the widget results to certain projects, environments, date ranges, and releases. You can also add custom filters to your dashboard by pressing the _plus_ button. Each filter begins with selecting a dataset, and then adding a filter condition.
+
+### Insights Page Filters
+

-If you want to see data for all your projects, click "Clear" in the project selector to clear any project filters.
+If you want to see data for all your projects, click "Clear" in the project selector to clear any project filters. Or search for specific data key value pairs by typing them in the search bar.
## Learn more
diff --git a/docs/contributing/approach/sdk-docs/write-getting-started.mdx b/docs/contributing/approach/sdk-docs/write-getting-started.mdx
index e39e25dee6f26..0d0762a2204f9 100644
--- a/docs/contributing/approach/sdk-docs/write-getting-started.mdx
+++ b/docs/contributing/approach/sdk-docs/write-getting-started.mdx
@@ -62,7 +62,7 @@ Add the configuration code sample to this directory:
-If the SDK supports performance monitoring, add it to the list that links back into the SDK content from Product, stored in [`/docs/product/insights/getting-started.mdx`](https://github.com/getsentry/sentry-docs/blob/master/docs/product/insights/getting-started.mdx).
+If the SDK supports performance monitoring, link to the [Sentry Dashboards](/product/dashboards/sentry-dashboards/) index (Set Up section with platform redirect to tracing). The per-SDK list for performance is no longer in docs; the index links to [Set up tracing for your platform](/platform-redirect/?next=%2Ftracing%2F).
diff --git a/docs/contributing/approach/sdk-docs/write-quick-start.mdx b/docs/contributing/approach/sdk-docs/write-quick-start.mdx
index 467d80871f14e..fa15a5d98c597 100644
--- a/docs/contributing/approach/sdk-docs/write-quick-start.mdx
+++ b/docs/contributing/approach/sdk-docs/write-quick-start.mdx
@@ -136,7 +136,7 @@ Integrate this content into your guide using the `PlatformSection` component.
If the SDK supports performance monitoring, add it to the list that links back
into the SDK content from Product, stored in
- [`/docs/product/insights/getting-started.mdx`](https://github.com/getsentry/sentry-docs/blob/master/docs/product/insights/getting-started.mdx).
+ [`/docs/product/dashboards/sentry-dashboards/index.mdx`](https://github.com/getsentry/sentry-docs/blob/master/docs/product/dashboards/sentry-dashboards/index.mdx) (Sentry Dashboards index, which includes a Set Up section and platform redirect to tracing).
## Additional Requirements for Our Wizard
diff --git a/docs/platforms/android/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/android/tracing/instrumentation/performance-metrics.mdx
index 99108a14cd57b..d6ddb557a8bed 100644
--- a/docs/platforms/android/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/android/tracing/instrumentation/performance-metrics.mdx
@@ -10,7 +10,7 @@ Sentry's SDKs support sending performance metrics data to Sentry. These are nume
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/apple/common/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/apple/common/tracing/instrumentation/performance-metrics.mdx
index d3e2b57dfbd61..2b082e678373c 100644
--- a/docs/platforms/apple/common/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/apple/common/tracing/instrumentation/performance-metrics.mdx
@@ -10,7 +10,7 @@ Sentry's SDKs support sending performance metrics data to Sentry. These are nume
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/dart/common/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/dart/common/tracing/instrumentation/performance-metrics.mdx
index 384956bc02fa4..19cd6887cfe3a 100644
--- a/docs/platforms/dart/common/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/dart/common/tracing/instrumentation/performance-metrics.mdx
@@ -8,7 +8,7 @@ Sentry's SDKs support sending performance metrics data to Sentry. These are nume
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/dart/guides/flutter/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/dart/guides/flutter/tracing/instrumentation/performance-metrics.mdx
index 99108a14cd57b..d6ddb557a8bed 100644
--- a/docs/platforms/dart/guides/flutter/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/dart/guides/flutter/tracing/instrumentation/performance-metrics.mdx
@@ -10,7 +10,7 @@ Sentry's SDKs support sending performance metrics data to Sentry. These are nume
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/dotnet/common/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/dotnet/common/tracing/instrumentation/performance-metrics.mdx
index 8955adc964609..6641b02737dee 100644
--- a/docs/platforms/dotnet/common/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/dotnet/common/tracing/instrumentation/performance-metrics.mdx
@@ -8,7 +8,7 @@ The SDK supports sending performance metrics data to Sentry. These are numeric v
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/java/common/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/java/common/tracing/instrumentation/performance-metrics.mdx
index 8955adc964609..6641b02737dee 100644
--- a/docs/platforms/java/common/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/java/common/tracing/instrumentation/performance-metrics.mdx
@@ -8,7 +8,7 @@ The SDK supports sending performance metrics data to Sentry. These are numeric v
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/powershell/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/powershell/tracing/instrumentation/performance-metrics.mdx
index 7115f88f18c31..df66c6ce5aae0 100644
--- a/docs/platforms/powershell/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/powershell/tracing/instrumentation/performance-metrics.mdx
@@ -8,7 +8,7 @@ Sentry's SDKs support sending performance metrics data to Sentry. These are nume
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/python/tracing/span-metrics/performance-metrics.mdx b/docs/platforms/python/tracing/span-metrics/performance-metrics.mdx
index 3869d416a690e..4001da4e71e73 100644
--- a/docs/platforms/python/tracing/span-metrics/performance-metrics.mdx
+++ b/docs/platforms/python/tracing/span-metrics/performance-metrics.mdx
@@ -10,7 +10,7 @@ The SDK supports sending performance metrics data to Sentry. These are numeric v
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/react-native/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/react-native/tracing/instrumentation/performance-metrics.mdx
index 2bf9fa5203420..a3d1ac0263c2f 100644
--- a/docs/platforms/react-native/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/react-native/tracing/instrumentation/performance-metrics.mdx
@@ -13,7 +13,7 @@ The React Native SDK automatically collects the following performance metrics:
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/ruby/common/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/ruby/common/tracing/instrumentation/performance-metrics.mdx
index 8955adc964609..6641b02737dee 100644
--- a/docs/platforms/ruby/common/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/ruby/common/tracing/instrumentation/performance-metrics.mdx
@@ -8,7 +8,7 @@ The SDK supports sending performance metrics data to Sentry. These are numeric v
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/platforms/unity/tracing/instrumentation/performance-metrics.mdx b/docs/platforms/unity/tracing/instrumentation/performance-metrics.mdx
index 7115f88f18c31..df66c6ce5aae0 100644
--- a/docs/platforms/unity/tracing/instrumentation/performance-metrics.mdx
+++ b/docs/platforms/unity/tracing/instrumentation/performance-metrics.mdx
@@ -8,7 +8,7 @@ Sentry's SDKs support sending performance metrics data to Sentry. These are nume
## Custom Measurements
-In addition to automatic performance metrics, the SDK supports setting [custom performance measurements](/product/insights/overview/metrics/#custom-performance-measurements) on transactions. This allows you to define measurements that are important to your application and send them to Sentry.
+In addition to automatic performance metrics, the SDK supports custom performance measurements on transactions.
To set a performance measurement, you need to supply the following:
diff --git a/docs/product/dashboards/custom-dashboards/img/create-dashboard.png b/docs/product/dashboards/custom-dashboards/img/create-dashboard.png
new file mode 100644
index 0000000000000..30d83763b48fe
Binary files /dev/null and b/docs/product/dashboards/custom-dashboards/img/create-dashboard.png differ
diff --git a/docs/product/dashboards/custom-dashboards/img/dashboard-edit.png b/docs/product/dashboards/custom-dashboards/img/dashboard-edit.png
deleted file mode 100644
index 62f9d1b231b55..0000000000000
Binary files a/docs/product/dashboards/custom-dashboards/img/dashboard-edit.png and /dev/null differ
diff --git a/docs/product/dashboards/custom-dashboards/img/dashboard-management.png b/docs/product/dashboards/custom-dashboards/img/dashboard-management.png
deleted file mode 100644
index 1bf924e472362..0000000000000
Binary files a/docs/product/dashboards/custom-dashboards/img/dashboard-management.png and /dev/null differ
diff --git a/docs/product/dashboards/custom-dashboards/img/dashboard-template.png b/docs/product/dashboards/custom-dashboards/img/dashboard-template.png
deleted file mode 100644
index bc28f6d3d4595..0000000000000
Binary files a/docs/product/dashboards/custom-dashboards/img/dashboard-template.png and /dev/null differ
diff --git a/docs/product/dashboards/custom-dashboards/index.mdx b/docs/product/dashboards/custom-dashboards/index.mdx
index 55199c794ec36..7c0e2db4d5d2f 100644
--- a/docs/product/dashboards/custom-dashboards/index.mdx
+++ b/docs/product/dashboards/custom-dashboards/index.mdx
@@ -2,42 +2,41 @@
title: Custom Dashboards
sidebar_order: 10
description: >-
- Learn how to edit or create additional dashboards to suit your organization's
+ Learn how to edit or create custom dashboards to suit your organization's
needs.
og_image: /og-images/product-dashboards-custom-dashboards.png
---
-Custom dashboards are shared across your organization, and users can view each other’s custom dashboards on the Dashboards home page. Note that any changes you make and **save** are global, and will appear for users across the entire organization.
+Custom dashboards are shared across your organization, and users can view each other’s custom dashboards on the [Dashboards home page](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/). Note that any changes you make and **save** become global, and will appear for users across the entire organization.
## Manage Dashboards
On the Dashboards home page, you can:
-- [Create a dashboard](#create-dashboards)
-- [Create a dashboard from a template](#create-dashboards-from-templates)
+- Create a dashboard
- Duplicate a dashboard
- Delete a dashboard
-
-
+- Categorize dashboards
### Create Dashboards
-Clicking "Create Dashboard" takes you to a new dashboard where you can immediately begin adding widgets. When you're creating a new dashboard or editing an existing one, the widgets are slightly grayed out. From here, you can:
+
+
+Clicking **Create Dashboard** takes you to a new dashboard where you can immediately begin adding widgets from a blank page. When you're creating a new dashboard or editing an existing one, the widgets are slightly grayed out. From here, you can:
-- Rename the dashboard
+- Name the dashboard
- Add and remove widgets
- Rearrange existing widgets
- Resize existing widgets
+- Create a custom widget
-
+### Duplicate Dashboards
-### Create Dashboards From Templates
-
-When the "Show Templates" toggle is enabled, several default dashboard templates are displayed. You can add each template directly to the list of dashboards by clicking "Add Dashboard", or preview it by clicking "Preview". You have to add a template before you can edit the resulting dashboard. You can also duplicate or delete a dashboard created from a template (this does not delete the template).
+You can duplicate a dashboard by clicking the ellipsis on a dashboard card and selecting **Duplicate**, or by clicking the **Duplicate** button on a dashboard page.
### Dashboard Filters
-Dashboard filters are applied to all the widgets in your dashboard. By default, they consist of [page filters](/concepts/search/#page-filters) that allow you to narrow down the widget results to certain projects, environments, date ranges, and releases. You can also add custom filters to your dashboard by pressing the _plus_ button. Each filter begins with selecting a dataset, and then adding a filter condition. You can add multiple filters to your dashboard, and they will be applied to all widgets in the dashboard. Changing a dashboard filter will prompt you to "Save" or "Cancel". To persist filter changes to your dashboard, click "Save", or click "Cancel" to discard the changes.
+Dashboard filters are applied to all the widgets in your dashboard. By default, they consist of page filters that allow you to narrow down the widget results to certain projects, environments, date ranges, and releases. You can also add custom filters to your dashboard by pressing the _plus_ button. Each filter begins with selecting a dataset, and then adding a filter condition. You can add multiple filters to your dashboard, and they will be applied to all widgets in the dashboard. Changing a dashboard filter will prompt you to "Save" or "Cancel". To persist filter changes to your dashboard, click "Save", or click "Cancel" to discard the changes.
### Dashboard Edit Access
@@ -47,14 +46,6 @@ To restrict who can edit or delete your dashboard, go to the "Edit Access" selec
When adding a widget or editing an existing one, you will be presented with a side panel where you can see the dashboard widget builder. The widget builder has several configuration options that you can use to shape data and add information to your dashboard. Learn more in the [Widget Builder documentation](/product/dashboards/widget-builder/).
-### Metrics Extraction
-
-
-
-If you're using custom tags or custom filters in your widgets, we will start collecting metrics to give you accurate counts and rates. During widget creation or editing, you will see approximate metrics for transaction datasets based on indexed events. As soon as you save, we will start extracting metrics for those widgets. It may take up to 15 minutes to start seeing metrics.
-
-Learn more about the feature and limitations of [metrics extraction](/product/dashboards/widget-builder/#extracted-metrics).
-
## Widget Library
The widget library contains a collection of prebuilt widgets you can add to your custom dashboards. Learn more by reading our [Widget Library docs](/product/dashboards/widget-library/).
diff --git a/docs/product/dashboards/index.mdx b/docs/product/dashboards/index.mdx
index a969b6705d70c..046956792419d 100644
--- a/docs/product/dashboards/index.mdx
+++ b/docs/product/dashboards/index.mdx
@@ -1,13 +1,13 @@
---
title: Dashboards
-sidebar_order: 100
+sidebar_order: 45
description: >-
- With Sentry’s Dashboards, you can get a focused view of your application’s
- health, while being able to easily navigate across multiple projects.
+ Learn how Sentry’s Dashboards give you a focused view of your application’s
+ health, across multiple projects.
og_image: /og-images/product-dashboards.png
---
-Sentry's Dashboards provide you with a broad overview of your application’s health by allowing you to navigate through error and performance data across multiple projects. Dashboards are made up of one or more widgets, and each widget visualizes one or more [dataset](/product/dashboards/widget-builder/#choose-your-dataset).
+Sentry's [Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/) provide you with a broad overview of your application’s health by allowing you to navigate through error and performance data across multiple projects. Dashboards are made up of one or more widgets, and each widget visualizes one or more [dataset](/product/dashboards/widget-builder/#choose-your-dataset). Try it out in a Dashboards sandbox.

@@ -26,13 +26,19 @@ You can also add custom global filters to your dashboard by pressing the _plus_
To restrict who can edit or delete your dashboard, go to the "Edit Access" selector. As the dashboard creator, you can limit access to specific teams by selecting the checkboxes in the Edit Access Selector and clicking Save Changes to apply the updates. Dashboard creators and organization owners always retain edit access.
+## Sentry Dashboards
+
+Sentry provides out-of-the-box [dashboards](/product/dashboards/sentry-dashboards/) for frontend, backend, mobile, and AI performance. These curated views give you a high-level overview of your application's health with widgets for Web Vitals, queries, outbound API requests, session health, and more. Use them to spot trends, drill into traces, and triage performance issues.
+
+You can also use these dashboards as templates by duplicating them to create your own custom dashboards.
+
## Custom Dashboards
-Every organization has a general template dashboard that is shared across all users. If you’d like to edit the default dashboard or build out new ones, each with its own set of unique widgets, you may want to consider the [Custom Dashboards](/product/dashboards/custom-dashboards/) feature which enables you to create more robust or customized views for example, to track performance of a specific feature or to track errors by a specific team's ownership.
+You can make [custom dashboards](/product/dashboards/custom-dashboards/) by duplicating an existing dashboard or starting from scratch by pressing the **Create Dashboard** button. Custom dashboards enable you to create views tailored to your organization's needs. For example, you may want to track performance of a specific feature, or track errors by a specific team's ownership. Once in edit mode, use the same filters you use to drill into a dashboard to customize your dashboard.
## Open Dashboard Widgets in Discover and Issues
-Each Dashboard widget has an ellipsis that opens a context menu. From here, depending on the type of data the widget shows, you can open the widget in [Discover](/product/explore/discover-queries/) or [Issues](/product/issues/) to get more information.
+Each dashboard [widget](/product/dashboards/widget-builder/) has an ellipsis that opens a context menu. From here, depending on the type of data the widget shows, you can open the widget in [Discover](/product/explore/discover-queries/) or [Issues](/product/issues/) to get more information.
## Widget Viewer
diff --git a/docs/product/dashboards/sentry-dashboards/INSIGHTS-TO-SENTRY-DASHBOARDS-MIGRATION.md b/docs/product/dashboards/sentry-dashboards/INSIGHTS-TO-SENTRY-DASHBOARDS-MIGRATION.md
new file mode 100644
index 0000000000000..bcea90da9289e
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/INSIGHTS-TO-SENTRY-DASHBOARDS-MIGRATION.md
@@ -0,0 +1,194 @@
+# Insights → Sentry Dashboards migration
+
+This document tracks link updates, product naming changes, and redirects when migrating from **Insights** to **Sentry dashboards** (`/product/dashboards/sentry-dashboards/`).
+
+## Decisions
+
+- **Path:** Use `sentry-dashboards` (plural). Base path: `/product/dashboards/sentry-dashboards/`.
+- **Images:** Migrate the associated `img` folder with each moved doc as needed.
+- **Performance Overhead:** Page is deleted; merge useful content into Sentry dashboards index or a short note. Add redirect so `/product/insights/performance-overhead/` → `/product/dashboards/sentry-dashboards/`. Update all links that point to it.
+- **Product naming:** Where the product is called "Insights," change to "Sentry dashboards" (or "Sentry Dashboards" as appropriate). Update both links and prose.
+
+---
+
+## Path mapping (old → new)
+
+Use this when updating links and when adding redirects (e.g. in `redirects.js` and `src/middleware.ts`).
+
+| Old path | New path |
+|---------|----------|
+| `/product/insights/` | `/product/dashboards/sentry-dashboards/` |
+| `/product/insights/overview/` | `/product/dashboards/sentry-dashboards/` (merged into index) |
+| `/product/insights/overview/transaction-summary/` | `/product/dashboards/sentry-dashboards/transaction-summary/` |
+| `/product/insights/overview/metrics/` | `/product/dashboards/sentry-dashboards/transaction-summary/#metrics-in-this-view` (performance-metrics page retired; content in Transaction Summary) |
+| `/product/insights/overview/filters-display/` | `/product/dashboards/sentry-dashboards/` (page deleted; redirect to index) |
+| `/product/insights/overview/filters-display/widgets/` | `/product/dashboards/sentry-dashboards/` (page deleted; redirect to index) |
+| `/product/insights/getting-started/` | `/product/dashboards/sentry-dashboards/` (Set Up section merged into index; no separate getting-started page) |
+| `/product/insights/performance-overhead/` | `/product/dashboards/sentry-dashboards/` (page deleted; redirect) |
+| `/product/insights/frontend/` | `/product/dashboards/sentry-dashboards/frontend/` |
+| `/product/insights/frontend/web-vitals/` | `/product/dashboards/sentry-dashboards/frontend/web-vitals/` |
+| `/product/insights/frontend/web-vitals/web-vitals-concepts/` | `/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/` |
+| `/product/insights/frontend/network-requests/` | `/product/dashboards/sentry-dashboards/outbound-api-requests/` |
+| `/product/insights/frontend/assets/` | `/product/dashboards/sentry-dashboards/frontend/assets/` |
+| `/product/insights/frontend/session-health/` | `/product/dashboards/sentry-dashboards/frontend/session-health/` |
+| `/product/insights/backend/` | `/product/dashboards/sentry-dashboards/backend/` |
+| `/product/insights/backend/queries/` | `/product/dashboards/sentry-dashboards/backend/queries/` |
+| `/product/insights/backend/requests/` | `/product/dashboards/sentry-dashboards/outbound-api-requests/` |
+| `/product/insights/backend/queue-monitoring/` | `/product/dashboards/sentry-dashboards/backend/queues/` |
+| `/product/insights/backend/queue-monitoring/queues-page/` | `/product/dashboards/sentry-dashboards/backend/queues/` |
+| `/product/insights/backend/caches/` | `/product/dashboards/sentry-dashboards/backend/caches/` |
+| `/product/insights/backend/caches/cache-page/` | `/product/dashboards/sentry-dashboards/backend/caches/` |
+| `/product/insights/mobile/` | `/product/dashboards/sentry-dashboards/mobile/` |
+| `/product/insights/mobile/mobile-vitals/` | `/product/dashboards/sentry-dashboards/mobile/mobile-vitals/` |
+| `/product/insights/mobile/mobile-vitals/app-starts/` | `/product/dashboards/sentry-dashboards/mobile/mobile-vitals/app-starts/` |
+| `/product/insights/mobile/mobile-vitals/screen-loads/` | `/product/dashboards/sentry-dashboards/mobile/mobile-vitals/screen-loads/` |
+| `/product/insights/mobile/network-requests/` | `/product/dashboards/sentry-dashboards/outbound-api-requests/` |
+| `/product/insights/mobile/session-health/` | `/product/dashboards/sentry-dashboards/mobile/session-health/` |
+| `/product/insights/web-vitals/` (no "frontend") | `/product/dashboards/sentry-dashboards/frontend/web-vitals/` |
+| `/product/insights/queries` (widgets.mdx used this) | `/product/dashboards/sentry-dashboards/backend/queries/` |
+| `/product/insights/requests` | `/product/dashboards/sentry-dashboards/outbound-api-requests/` |
+| `/product/insights/caches/` | `/product/dashboards/sentry-dashboards/backend/caches/` |
+
+**AI:** Leave under `docs/ai/`. No URL changes for AI monitoring docs. Links that pointed to `/product/insights/ai/*` should be updated to the current `docs/ai` URLs (e.g. `/ai/monitoring/agents/`, `/ai/monitoring/mcp/`).
+
+---
+
+## Files to update (links) — outside `docs/product/insights/`
+
+Update these files to use the new paths from the table above. Replace any `/product/insights/...` with the corresponding `/product/dashboards/sentry-dashboards/...` (or merged path).
+
+### Product docs
+
+- `docs/product/alerts/alert-types.mdx` — metrics, latency, Apdex, failure rate, throughput
+- `docs/product/alerts/index.mdx` — metrics, latency, failure rate
+- `docs/product/dashboards/widget-library/index.mdx` — Apdex
+- `docs/product/issues/issue-details/performance-issues/index.mdx` — Insights and Tracing
+- `docs/product/issues/issue-details/performance-issues/web-vitals/index.mdx` — Web Vitals, opportunity
+- `docs/product/issues/issue-details/performance-issues/endpoint-regressions/index.mdx` — Span Summary / transaction-summary
+- `docs/product/projects/project-details/index.mdx` — Apdex, failure rate, TPM
+- `docs/product/releases/release-details.mdx` — Failure Rate
+- `docs/product/explore/discover-queries/query-builder/query-equations.mdx` — Apdex
+- `docs/product/explore/profiling/mobile-app-profiling/metrics.mdx` — Mobile Vitals
+- `docs/product/sentry-basics/integrate-frontend/configure-scms.mdx` — Insights
+- `docs/product/sentry-basics/performance-monitoring.mdx` — (if it links to insights; verify)
+- `docs/product/crons/alerts-backend-insights-migration.mdx` — "Insights > Backend" (naming)
+- `docs/product/pricing/legacy-pricing.mdx` — Insights features
+- `docs/product/dotnet/common/enriching-events/transaction-name/index.mdx` — Insights product (naming + link)
+
+### Concepts
+
+- `docs/concepts/key-terms/key-terms.mdx` — Insights Overview, performance monitoring
+- `docs/concepts/key-terms/tracing/index.mdx` — Insights page, caching issues, Learn more Insights
+- `docs/concepts/key-terms/tracing/distributed-tracing.mdx` — metrics
+- `docs/concepts/search/searchable-properties/issues.mdx` — transactions, transaction-summary
+- `docs/concepts/search/searchable-properties/events.mdx` — Apdex, User Misery
+
+### Platforms (tracing / overview)
+
+- `docs/platforms/android/tracing/index.mdx` — tracing/overview
+- `docs/platforms/android/overhead/index.mdx` — **performance-overhead** → sentry-dashboards
+- `docs/platforms/android/enriching-events/transaction-name/index.mdx` — Insights product
+- `docs/platforms/apple/common/overhead/index.mdx` — **performance-overhead** → sentry-dashboards
+- `docs/platforms/apple/common/features/index.mdx` — Tracing, Mobile Vitals
+- `docs/platforms/apple/common/tracing/instrumentation/automatic-instrumentation.mdx` — Mobile Vitals (×2)
+- `docs/platforms/apple/common/tracing/instrumentation/swiftui-instrumentation.mdx` — Mobile Vitals TTID/TTFD
+- `docs/platforms/apple/common/tracing/instrumentation/performance-metrics.mdx` — custom performance measurements
+- `docs/platforms/apple/guides/visionos/features/index.mdx` — Frame rate / mobile-vitals
+- `docs/platforms/apple/guides/tvos/features/index.mdx` — Frame rate
+- `docs/platforms/apple/guides/macos/features/index.mdx` — Frame rate
+- `docs/platforms/dart/common/features/index.mdx` — Tracing/overview
+- `docs/platforms/dart/common/tracing/instrumentation/performance-metrics.mdx` — custom performance measurements
+- `docs/platforms/dart/common/overhead/index.mdx` — **performance-overhead** → sentry-dashboards
+- `docs/platforms/dart/guides/flutter/tracing/index.mdx` — tracing/overview
+- `docs/platforms/dart/guides/flutter/tracing/instrumentation/performance-metrics.mdx` — (if present; verify)
+- `docs/platforms/dart/guides/flutter/overhead/index.mdx` — **performance-overhead** → sentry-dashboards
+- `docs/platforms/dotnet/common/tracing/index.mdx` — tracing/overview
+- `docs/platforms/dotnet/common/enriching-events/transaction-name/index.mdx` — Insights product
+- `docs/platforms/javascript/common/configuration/integrations/browsertracing.mdx` — tracing/overview
+- `docs/platforms/javascript/common/tracing/instrumentation/automatic-instrumentation.mdx` — Mobile Vitals, Web Vitals
+- `docs/platforms/powershell/tracing/instrumentation/performance-metrics.mdx` — custom performance measurements
+- `docs/platforms/react-native/tracing/instrumentation/performance-metrics.mdx` — custom performance measurements
+- `docs/platforms/react-native/tracing/instrumentation/time-to-display.mdx` — Mobile Vitals TTID/TTFD
+- `docs/platforms/react-native/tracing/instrumentation/automatic-instrumentation.mdx` — Mobile Vitals, Web Vitals
+- `docs/platforms/react-native/overhead/index.mdx` — **performance-overhead** → sentry-dashboards
+- `docs/platforms/react-native/enriching-events/transaction-name/index.mdx` — Insights product
+- `docs/platforms/ruby/common/migration.mdx` — tracing/overview
+- `docs/platforms/rust/common/tracing/index.mdx` — Insights
+- `docs/platforms/unity/tracing/index.mdx` — tracing/overview
+- `docs/platforms/unity/tracing/instrumentation/performance-metrics.mdx` — custom performance measurements
+- `docs/platforms/unreal/tracing/index.mdx` — tracing/overview
+
+### Guides & other
+
+- `docs/guides/custom-spans.mdx` — Sentry Agent Monitoring (`/product/insights/ai/agents/`) → use `/ai/monitoring/agents/` (or current AI doc URL)
+- `docs/contributing/approach/sdk-docs/write-getting-started.mdx` — points to insights getting-started; update path to sentry-dashboards getting-started (or index)
+
+### Develop-docs (optional)
+
+- `develop-docs/backend/application-domains/transaction-clustering/index.mdx` — Insights product, metrics
+- `develop-docs/sdk/telemetry/traces/opentelemetry.mdx` — performance monitoring product
+
+### Middleware and redirects
+
+- **`src/middleware.ts`:**
+ - Change every `to: '/product/insights/...'` to the new destination (see path mapping).
+ - `to: '/product/insights/performance-overhead/'` → `to: '/product/dashboards/sentry-dashboards/'`.
+ - `to: '/product/insights/retention-priorities/'` → `to: '/organization/dynamic-sampling/'`.
+ - Remove or replace redirect to `/product/insights/overview/trends/` (e.g. send `/product/performance/trends/` to `/product/dashboards/sentry-dashboards/`).
+- **`redirects.js`:** Add redirects for all old `/product/insights/*` URLs to the new sentry-dashboards paths. `redirects.js` already has `product/insights/retention-priorities/` → `organization/dynamic-sampling/`; add the rest of the insights → sentry-dashboards mappings.
+
+---
+
+## Product naming (Insights → Sentry dashboards)
+
+Where the **product** is named "Insights," change to "Sentry dashboards" (or "Sentry Dashboards" where appropriate). Examples:
+
+- "Insights" (standalone) → "Sentry dashboards"
+- "Insights tab" → "Sentry Dashboards tab" or "dashboards"
+- "Insights Overview" → "Sentry Dashboards" or "Sentry dashboards overview" (depending on context after merge)
+- "Insights and Tracing" → "Sentry dashboards and Tracing" or "Sentry Dashboards and tracing"
+- "Insight Domain" → "Sentry dashboards domain" or rephrase
+- "Insights for Mobile Vitals" → "Sentry dashboards for Mobile Vitals" or "Mobile Vitals in Sentry Dashboards"
+- "[Insights](/product/insights/)" → "[Sentry dashboards](/product/dashboards/sentry-dashboards/)"
+
+**Files to review for naming (in addition to link updates above):**
+
+- `docs/product/insights/*` (content that moves into sentry-dashboards): replace "Insights" with "Sentry dashboards" in titles, descriptions, and body.
+- `docs/product/sentry-basics/performance-monitoring.mdx` — "Insights" pages
+- `docs/product/issues/issue-details/performance-issues/index.mdx` — "Insights and Tracing"
+- `docs/product/crons/alerts-backend-insights-migration.mdx` — "Insights > Backend"
+- `docs/concepts/key-terms/key-terms.mdx` — "Insights Overview"
+- `docs/concepts/key-terms/tracing/index.mdx` — "Insights" page, "Sentry's Insights"
+- `docs/platforms/dotnet/common/enriching-events/transaction-name/index.mdx` — "Insights product"
+- `docs/platforms/react-native/enriching-events/transaction-name/index.mdx` — "Insights product"
+- `docs/platforms/android/enriching-events/transaction-name/index.mdx` — "Insights product"
+- `docs/product/pricing/legacy-pricing.mdx` — "Insights features"
+
+---
+
+## Performance Overhead
+
+- **Page:** `docs/product/insights/performance-overhead.mdx` is deleted; content merged or summarized in Sentry dashboards index.
+- **Redirect:** Add (in `redirects.js` or middleware):
+ `/product/insights/performance-overhead/` → `/product/dashboards/sentry-dashboards/`
+- **Links to update (→ `/product/dashboards/sentry-dashboards/`):**
+ - `docs/platforms/android/overhead/index.mdx`
+ - `docs/platforms/apple/common/overhead/index.mdx`
+ - `docs/platforms/dart/common/overhead/index.mdx`
+ - `docs/platforms/dart/guides/flutter/overhead/index.mdx`
+ - `docs/platforms/react-native/overhead/index.mdx`
+- **Middleware:** Update rule that sends old performance-overhead URL to insights; point to sentry-dashboards instead.
+
+---
+
+## Summary checklist
+
+- [ ] Move/merge all content from `docs/product/insights/` to `docs/product/dashboards/sentry-dashboards/` per migration plan (including single `queues.mdx`, merged outbound-api-requests, etc.).
+- [ ] Migrate `img` folders with each moved doc; fix image paths in MDX.
+- [ ] Update every link in the "Files to update" list to use new paths (path mapping table).
+- [ ] Replace product name "Insights" with "Sentry dashboards" in moved content and in the "Product naming" files.
+- [ ] Add redirects for all old `/product/insights/*` URLs to new sentry-dashboards URLs (redirects.js and/or middleware).
+- [ ] Performance overhead: redirect + update 5 platform overhead docs.
+- [ ] Middleware: retention-priorities → `/organization/dynamic-sampling/`; trends → remove or send to sentry-dashboards.
+- [ ] Fix widgets.mdx Queries link: `/product/insights/queries` → `/product/dashboards/sentry-dashboards/backend/queries/` (in migrated/salvaged content).
+- [ ] AI: ensure any remaining `/product/insights/ai/*` links point to current `docs/ai` URLs (e.g. `/ai/monitoring/agents/`).
diff --git a/docs/product/dashboards/sentry-dashboards/ai/index.mdx b/docs/product/dashboards/sentry-dashboards/ai/index.mdx
new file mode 100644
index 0000000000000..5b5a7acf44bc6
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/ai/index.mdx
@@ -0,0 +1,12 @@
+---
+title: AI
+sidebar_order: 50
+description: "Use Sentry Dashboards to monitor AI agents and MCP performance."
+---
+
+Sentry Dashboards include dedicated views for AI monitoring. Use them to track agent executions, token usage, tool calls, and MCP (Model Context Protocol) traffic.
+
+- **[AI Agents Dashboard](/ai/monitoring/agents/dashboard/)** — View AI agent workflows, model costs, token usage, and tool calls. See [Set up AI Agent Monitoring](/ai/monitoring/agents/getting-started/) to get started.
+- **[MCP Dashboard](/ai/monitoring/mcp/dashboard/)** — Monitor MCP server usage and performance. See [Set up MCP](/ai/monitoring/mcp/getting-started/) to get started.
+
+For data privacy and security, see [AI Agents Data Privacy](/ai/monitoring/agents/privacy/).
diff --git a/docs/product/dashboards/sentry-dashboards/backend/caches.mdx b/docs/product/dashboards/sentry-dashboards/backend/caches.mdx
new file mode 100644
index 0000000000000..3448e24f78ab2
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/backend/caches.mdx
@@ -0,0 +1,54 @@
+---
+title: "Caches"
+sidebar_order: 70
+description: "Learn more about cache monitoring with Sentry and how it can help improve your application's performance."
+---
+
+A cache can be used to speed up data retrieval, improving application performance. It temporarily stores data to speed up subsequent access to that data, allowing your application to get data from cached memory (if it is available) instead having to repeatedly fetch the data from a potentially slow data layer. Caching can speed up read-heavy workloads for applications like Q&A portals, gaming, media sharing, and social networking.
+
+A successful cache results in a high hit rate which means the data was present when fetched. A cache miss occurs when the data fetched was not present in the cache. If you have [performance monitoring](/product/sentry-basics/performance-monitoring/#how-to-set-up-performance-monitoring) enabled and your application uses caching, you can see how your caches are performing with Sentry.
+
+Sentry's cache monitoring provides insights into cache utilization and latency to help you improve performance on endpoints that interact with caches.
+
+With the Cache dashboard found in [Sentry Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/), you get an overview of the transactions within your application that are making at least one lookup against a cache. From there, you can dig into specific cache span operations by clicking a transaction and viewing its sample list.
+
+
+{/* */}
+
+## Instrumentation
+
+Cache monitoring currently supports [auto instrumentation](/platform-redirect/?next=%2Ftracing%2Finstrumentation%2Fautomatic-instrumentation) for [Django's cache framework](https://docs.djangoproject.com/en/5.0/topics/cache/) when the [cache_spans option](/platforms/python/integrations/django/#options) is set to `True`. Other frameworks require custom instrumentation.
+
+### Custom instrumentation
+
+If available, custom instrumentation is documented on an environment-by-environment basis as listed below:
+
+- [Python SDK](/platforms/python/tracing/instrumentation/custom-instrumentation/caches-module/)
+- [JavaScript SDKs](/platforms/javascript/guides/node/tracing/instrumentation/custom-instrumentation/caches-module/)
+- [PHP SDK](/platforms/php/tracing/instrumentation/caches-module/)
+- [Java SDK](/platforms/java/tracing/instrumentation/custom-instrumentation/caches-module/)
+- [Ruby SDK](/platforms/ruby/tracing/instrumentation/custom-instrumentation/caches-module/)
+- [.NET SDK](/platforms/dotnet/tracing/instrumentation/custom-instrumentation/caches-module/)
+
+To see what cache data can be set on spans, see the [Cache Module Developer Specification](https://develop.sentry.dev/sdk/performance/modules/caches/).
+
+## Caches Dashboard
+
+The **Caches** dashboard gives an overview of cache performance across all endpoints for currently selected backend projects with summary graphs for **Miss Rate** and **Requests Per Minute** (throughput). You can use these as a starting point to see if there are any potential cache performance issues, for example, a higher than expected Miss Rate percentage.
+
+If you see an anomaly or want to investigate a time range further, click and drag to select a range directly in the graph and data will be filtered for that specific time range only.
+
+The transaction table shows a list of endpoints that contain at least one `cache.get` span along with:
+
+- Its average value size (the bytes being fetched from cache)
+- Requests per minute
+- Miss rate percentage (how often did a lookup did not return a value)
+- Time spent (total time your application spent on a given transaction)
+
+By default, this table is sorted by most time spent. This means that endpoints at the top are usually really slow, requested very frequently, or both.
+
+Click on a transaction to go to the Transaction Summary page, or explore span samples on the Traces page.
+
+## Sample List
+
+To help you compare the performances of cache hits (where a value was found in the cache) versus misses (where no value corresponding to the key was found in the cache) over time, Sentry automatically surfaces a distribution of both samples for the timeframe selected from the **Caches** dashboard by clicking on a transaction and selecting to **View span samples**. Drill into any span on the Traces page to see a waterfall view.
diff --git a/docs/product/dashboards/sentry-dashboards/backend/index.mdx b/docs/product/dashboards/sentry-dashboards/backend/index.mdx
new file mode 100644
index 0000000000000..23b53f8674b09
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/backend/index.mdx
@@ -0,0 +1,22 @@
+---
+title: Backend Dashboards
+sidebar_order: 20
+description: >-
+ Learn how to use Sentry's Backend Overview dashboards to monitor things like
+ queries, outbound API requests, caches, and queues.
+og_image: /og-images/product-insights-backend.png
+---
+
+Sentry's [**Backend dashboards**](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/) page gives you an overview of the health of your application.
+
+## Backend Overview Dashboard
+
+Start with the **Backend Overview** dashboard to get a quick overview of your application. See things like **Most Time-Consuming Queries**, **Most Time-Consuming Domains**, **p50** and **p75 Duration**, and so on.
+
+
+
+You can also dive deeper into Queries, Outbound API Requests, Caches, and Queues to get detailed information about potential issues affecting your application's health.
+
+## Learn More
+
+
diff --git a/docs/product/dashboards/sentry-dashboards/backend/queries.mdx b/docs/product/dashboards/sentry-dashboards/backend/queries.mdx
new file mode 100644
index 0000000000000..1dd560b8d252e
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/backend/queries.mdx
@@ -0,0 +1,122 @@
+---
+title: Queries
+sidebar_order: 0
+description: >-
+ With Queries in Sentry, you can easily see database queries, remediate
+ performance errors & monitor query performance.
+og_image: /og-images/product-insights-backend-queries.png
+---
+
+With the Queries dashboard in [Sentry Dashboards](/product/dashboards/sentry-dashboards/), when your application queries a database, you can see how your queries are performing in Sentry.
+
+Sentry's query monitoring helps you investigate the performance of your queries and get more information to improve them.
+
+Starting with the [Queries overview dashboard](#queries-overview-dashboard), you get a high-level view of how your queries are doing. From there, you can drill into a specific query's [Query Details dashboard](#query-details-dashboard) and investigate sample events from the [Sample List](#sample-list) to better understand the context of their performance for a specific endpoint.
+
+{/* */}
+
+
+
+## Prerequisites and Limitations
+
+The queries widget and dashboards are only available for backend projects with [performance monitoring](/product/sentry-basics/performance-monitoring/#how-to-set-up-performance-monitoring) enabled.
+
+### Recommended SDK Versions
+
+Query monitoring works best with up-to-date SDK versions. The following minimum versions are recommended:
+
+- [Python SDK v1.29.2](https://github.com/getsentry/sentry-python/releases/tag/1.29.2)
+- [JavaScript SDKs v7.63.0](https://github.com/getsentry/sentry-javascript/releases/tag/7.63.0)
+- [Laravel SDK v3.8.0](https://github.com/getsentry/sentry-laravel/releases/tag/3.8.0)
+- [Cocoa SDK v8.11.0](https://github.com/getsentry/sentry-cocoa/releases/tag/8.11.0)
+- [Java SDK v6.29.0](https://github.com/getsentry/sentry-java/releases/tag/6.29.0)
+- [Ruby SDK v5.11.0](https://github.com/getsentry/sentry-ruby/releases/tag/5.11.0)
+- [.NET SDK v3.39.0](https://github.com/getsentry/sentry-dotnet/releases/tag/3.39.0)
+- [Symfony SDK v4.11.0](https://github.com/getsentry/sentry-symfony/releases/tag/4.11.0)
+- [Android SDK v6.30.0](https://github.com/getsentry/sentry-java/releases/tag/6.30.0)
+
+### Span Eligibility
+
+Sentry tries to extract metrics for all SQL-like dialects, as well as MongoDB. Other NoSQL databases like Elasticsearch, graph databases like Neo4j, and other non-SQL database systems are not currently eligible for this feature.
+
+If you are using automatic instrumentation, query performance monitoring should work without any configuration. If you've manually instrumented Sentry, you'll need to make sure that your spans conform to our standards for the best experience:
+
+- The span `op` field is set to an [eligible value](https://develop.sentry.dev/sdk/performance/span-operations/#database).
+- The span's description contains the full, parameterized query (e.g. `"SELECT * FROM users WHERE id = ?"`). Supported placeholder values for SQL are `%s`, `?`, `:c0` (e.g. `:c0`, `:c1`) and `$1` (e.g. `$1`, `$2`). MongoDB span descriptions should contain valid JSON, and placeholders should be the string `"?"`.
+- The `db.system` span data value is set to the [correct identifier](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/db/database-spans.md) (e.g., `"postgresql"` or `"mongodb"`).
+
+## Queries Overview Dashboard
+
+The Queries dashboard gives you a quick overview of your application's query performance for the selected project(s). You can use this dashboard as a starting point to investigate potential problem queries and drill down to better understand how various queries are affecting your app's performance.
+
+Open the Queries dashboard in [Sentry Dashboards](/product/dashboards/sentry-dashboards/).
+
+Get high-level insights into database performance using summary graphs for queries per minute (throughput) and average duration. If you see an anomaly or want to investigate a time range further, you can click and drag to select a range directly in a graph to filter data for that range.
+
+The query description table shows a list of queries, their volume (queries per minute), average duration, and the total time your app spent running that query (time spent). The query descriptions are parametrized, so your queries may look slightly different.
+
+By default, this table is sorted by most [time spent](#what-is-time-spent). This means that queries at the top are usually really slow, very frequent, or both. You can change this to sort by queries per minute to see the most frequently run queries, or by average duration to see the slowest queries.
+
+You can also use the [global and custom filters](/product/dashboards/#global-filters) to filter all data for specific commands (such as `SELECT` and `UPDATE`) and tables/collections queried.
+
+To view more details, click on a query from the table to open its Query Details dashboard.
+
+### Query Parameterization
+
+Sometimes, Sentry processes queries and simplifies them to improve readability. For example, for SQL queries:
+
+- Table names are removed from column selections if possible (e.g., `SELECT "users"."name", "users"."id", "users.age" FROM users` becomes `SELECT name, id, age FROM users`)
+- Long lists of `SELECT` arguments are collapsed (e.g., `SELECT id, name, age, city, country, phone FROM users` becomes `SELECT .. FROM users`)
+- Long lists of `VALUES` arguments are collapsed (e.g., `INSERT INTO users (id, email, name, age) VALUES (%s %s %s %s)` becomes `INSERT INTO users (..) VALUES (%s)`)
+- `CASE / WHEN` statements are collapsed
+
+For MongoDB queries:
+
+- Leaf values are replaced with the placeholder `"?"`
+- A maximum depth is applied to deeply nested query objects
+
+You can see the full query by hovering on a truncated description, or clicking it to see its **Query Details** dashboard.
+
+## Query Details Dashboard
+
+To open a single query's **details** dashboard, click on the query from either the table in the "Queries by Time Spent" widget on the Backend Overview dashboard or the table in the Queries dashboard.
+
+Start with queries per minute, average duration, and time spent for the selected time range. The full query is shown below these metrics, followed by graphs for queries per minute and average duration. The query's source in the code is also shown if it is available.
+
+At the bottom, you can find a list of endpoints the query is found in, sorted by the most time your application spent in that span.
+
+If you want to investigate a specific endpoint, click on it to open a sidebar showing some sample events.
+
+## Query Sources
+
+
+
+Query Sources are currently supported in Sentry's [Laravel](/platforms/php/guides/laravel/configuration/laravel-options/#more-configuration) (enabled by default) and [Python](/platforms/python/configuration/options/#enable-db-query-source) (enabled by default) SDKs. Sentry only attaches query sources to queries that are slower than a configurable threshold ([Python](/platforms/python/configuration/options/#db-query-source-threshold-ms), [Laravel](/platforms/php/guides/laravel/configuration/laravel-options/#more-configuration)) to reduce the performance impact.
+
+
+
+A query's source is the location in your application's code that triggered the query. Sentry automatically determines the query source by examining the [stack trace](/product/sentry-basics/integrate-frontend/upload-source-maps/) and attaches the source to the query data.
+
+You can see the query's source underneath the query description on the **Query Details** dashboard, as shown in the image below. If you have a [source code management integration](/organization/integrations/source-code-mgmt/) enabled, Sentry will also show a link to open the query's source in the relevant repository.
+
+
+
+## Sample List
+
+Click on an endpoint to go to its samples list. This traces page shows summary metrics (like EPM, average, and sum duration) for the query in the specific endpoint.
+
+The table shows a sample list of events, their span duration, and the difference in duration compared to the average. This table is sorted by longest span duration.
+
+Sentry automatically finds a variety of samples to help you investigate performance problems. The chosen events will cover the entire selected time range, as well as a range of durations (both faster than, slower than, and near the average duration). You can get a sense of the performance characteristics by comparing different sample events.
+
+From the sample list, you can drill down to specific good, average, or bad examples of a given query within a given endpoint. Click on an event ID to drill into the query's span details within the span waterfall of the [Trace View page](/concepts/key-terms/tracing/trace-view/).
+
+## What is Time Spent?
+
+By default, queries are sorted by **time spent**, which serves as a proxy for the relative impact of a given query.
+
+Every database query takes some time to execute. When an application sends a query, it waits for the database to receive the query, parse it, execute it, and return the result. In Sentry, the total time taken from sending the query to receiving the full result is called the query's **duration**. The query's **time spent** is the sum of all its durations in a given period.
+
+For example, an application might send a query like `SELECT * FROM users LIMIT 10` every time a user calls the `/users` endpoint. The query might take anywhere from 100ms to 200ms to run, and the endpoint is called anywhere from 10 times a minute to 100 times in a minute depending on the time of day. The query's time spent is the sum of all of its durations that occurred in a given period. Put another way, the time spent is the product of the average duration and queries per minute. In a high-throughput application, a query's time spent might be measured in weeks or months.
+
+Time spent is a useful way to measure a query's relative impact, compared to other queries in an application. For example, if one query's time spent is 7 days, and another is just 2 hours, the query with more time spent is probably more impactful to fix. Even a small improvement in duration would result in a meaningful overall improvement. Time spent can also be a strong signal that something is wrong. Queries that suddenly start taking up more time often signal a problem.
diff --git a/docs/product/dashboards/sentry-dashboards/backend/queues.mdx b/docs/product/dashboards/sentry-dashboards/backend/queues.mdx
new file mode 100644
index 0000000000000..b7dd1dd9f941c
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/backend/queues.mdx
@@ -0,0 +1,75 @@
+---
+title: "Queues"
+sidebar_order: 30
+description: "Learn how to monitor your queues with Sentry for improved application performance and health."
+---
+
+Message Queues make asynchronous service-to-service communication possible in distributed architectures. Queues are great for helping work that sometimes fails become more resilient, and therefore a building block for distributed applications. Some examples of what queues can help with include handling webhooks from third-party APIs or handling periodic tasks, such as calculating daily metrics for your users.
+
+If you have [performance monitoring](/product/sentry-basics/performance-monitoring/#how-to-set-up-performance-monitoring) enabled and your application interacts with message queue systems, you can configure Sentry to monitor their performance and health.
+
+Queues allows you to monitor both the performance and error rates of both your queue consumers and producers, providing observability into your distributed system.
+
+The Queues dashboard found in [Sentry Dashboards](/product/dashboards/sentry-dashboards/) gives you a high-level overview so that you can see where messages are being written to. **Note:** You may see topic names or actual queue names, depending on the messaging system. If you click on a destination, you'll go to the **Queue Details** dashboard, which provides metrics about specific endpoints within your applications that either write to, or read from the destination. You can also dig into individual endpoints within your application representing producers creating messages, and consumers reading messages. In those lists, you'll see actual traces representing messages processed by your application.
+
+{/* */}
+
+### Prerequisites and Limitations
+
+Queues currently supports [auto instrumentation](/platform-redirect/?next=%2Ftracing%2Finstrumentation%2Fautomatic-instrumentation) for the [Celery Distributed Task Queue](https://docs.celeryq.dev/en/stable/) in Python. Other messaging systems can be monitored using custom instrumentation.
+
+Instructions for custom instrumentation in various languages are linked to below:
+
+- [Python SDK](/platforms/python/tracing/instrumentation/custom-instrumentation/queues-module/)
+- [JavaScript SDK](/platforms/javascript/guides/node/tracing/instrumentation/custom-instrumentation/queues-module/)
+- [PHP SDK](/platforms/php/tracing/instrumentation/queues-module/)
+- [Java SDK](/platforms/java/tracing/instrumentation/custom-instrumentation/queues-module/)
+- [Ruby SDK](/platforms/ruby/tracing/instrumentation/custom-instrumentation/queues-module/)
+- [.NET SDK](/platforms/dotnet/tracing/instrumentation/custom-instrumentation/queues-module/)
+
+## Queues Dashboard
+
+The **Queues** dashboard provides a breakdown of queue performance by destination (the topic name or queue name). Use it as a starting point to investigate potential problems with queues, such as higher than expected processing latency.
+
+At the top of the dashboard, the Average Duration graph shows the total time that messages take to complete. The Published versus Processed graph shows how many messages are being written to the queue versus how many are being completed. If you see an anomaly or want to investigate a time range further, click and drag to select a range directly in the graph and you'll see data for that specific time range only.
+
+The destination table shows where messages are being published to, along with:
+
+- Avg time in queue (the time spent both waiting and being processed in the queue)
+- Avg processing time (the time spent processing the message)
+- Error rate (how often do jobs fail to complete)
+- Published versus processed count
+- Processed (messages per minute)
+- Time spent (total time your application spent processing jobs)
+
+If you want to dig deeper into the behavior of a specific destination, click the destination name to view the **Queue Details** dashboard.
+
+## Queue Details Dashboard
+
+To view the **Queue Details** dashboard click a [destination](https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#destinations) in the **Queues** dashboard.
+
+At the top of the dashboard you'll see average time in queue, average processing latency, error rate, published versus processed counts, and the total time spent by your application processing jobs. These metrics are shown in relation to the destination, whereas the **Queues** dashboard shows summed up metrics across all destinations. Below the summary you can view graphs for average latency and published versus processed counts.
+
+At the bottom of the dashboard, a table is shown listing transactions that either published or processed queue messages.
+
+If a problem with a specific endpoint jumps out at you, click the transaction to view sample spans and to navigate to the corresponding trace.
+
+### Sample List
+
+Click on an endpoint to open a list of sample spans. This will take you to the traces page for that transaction.
+
+### Producer Sample List
+
+Sentry automatically finds a variety of samples to help you investigate performance problems. The chosen spans cover the entire selected time range, as well as a range of durations and failure statues.
+
+The Producer panel shows the number of messages the producer has published, the error rate (representing errors that occur while publishing the message), and the average duration of the transaction that publishes the message to the queue.
+
+To dig even deeper, click on a span identifier to view a detailed trace.
+
+### Consumer Sample List
+
+Sentry automatically finds a variety of samples to help you investigate performance problems. The chosen spans cover the entire selected time range, as well as a range of durations and failure statues.
+
+The Consumer panel shows the number of messages the consumer has processed, the error rate, the average time a message spends in a queue, and the average amount of time spent processing the message.
+
+To dig even deeper, click on a transaction to go to the transaction summary page, or a span in the traces page to see a waterfall view of the span.
\ No newline at end of file
diff --git a/docs/product/dashboards/sentry-dashboards/frontend/assets.mdx b/docs/product/dashboards/sentry-dashboards/frontend/assets.mdx
new file mode 100644
index 0000000000000..744c172a2cbb1
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/frontend/assets.mdx
@@ -0,0 +1,159 @@
+---
+title: Assets
+sidebar_order: 20
+description: >-
+ Learn more about browser asset performance monitoring, which allows you to
+ debug the performance of loading JavaScript and CSS on your frontend.
+og_image: /og-images/product-insights-frontend-assets.png
+---
+
+If you have [tracing](/product/sentry-basics/tracing/) enabled for your frontend, you can see how your browser assets are performing in Sentry.
+
+Starting with the [Assets dashboard](#assets-dashboard), you get a high-level overview of how your assets are doing. From there, you can drill into a specific asset's [Asset Summary dashboard](#asset-summary-dashboard) and then investigate sample events from the [Sample List](#sample-list) to better understand the context of its performance in a specific page.
+
+## Prerequisites and Limitations
+
+The asset pages are only available for frontend JavaScript projects with performance monitoring enabled. Currently only JavaScript, CSS, images, and certain assets that are initiated by CSS (such as fonts), are supported.
+
+For the best experience, we recommend enabling automatic instrumentation via the `BrowserTracing` integration for your frontend project to see asset performance data. This is supported for the following JavaScript platforms:
+
+- [Vanilla JavaScript](/platforms/javascript/performance/)
+- [Angular](/platforms/javascript/guides/angular/performance/)
+- [Astro](/platforms/javascript/guides/astro/performance/)
+- [Ember](/platforms/javascript/guides/ember/performance/)
+- [Gatsby](/platforms/javascript/guides/gatsby/performance/)
+- [Next.js](/platforms/javascript/guides/nextjs/performance/)
+- [React](/platforms/javascript/guides/react/performance/)
+- [Remix](/platforms/javascript/guides/remix/performance/)
+- [Svelte](/platforms/javascript/guides/svelte/performance/)
+- [SvelteKit](/platforms/javascript/guides/sveltekit/performance/)
+- [Vue](/platforms/javascript/guides/vue/performance/)
+
+### Span Eligibility
+
+Sentry tries to extract metrics by looking at asset-related spans.
+
+The JavaScript SDK automatically generates `asset` spans on `pageload` and `navigation` transactions using the browser's [Resource Timing API](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Resource_timing).
+
+If you are using automatic instrumentation, asset monitoring should work without any configuration.
+
+If you've manually instrumented Sentry, you'll need to make sure that your spans conform to our standards for the best experience:
+
+- The span `op` field is prefixed with `resource` (for example, `resource.script` or `resource.css`).
+- The span's `description` contains the URL of the loaded resource, which should correspond to the [PerformanceResourceTiming name field](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEntry/name).
+- The `http.response_transfer_size` span data value is set to the [total transfer size](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize) of the resource.
+- The `http.response_content_length` span data value is set to the [encoded body size](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/encodedBodySize) of the resource.
+- The `http.decoded_response_content_length` span data value is set to the [decoded body size](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/decodedBodySize) of the resource.
+- The `resource.render_blocking_status` span data value is set to the [render blocking status](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/renderBlockingStatus) of the resource.
+
+Here's an example snippet of creating a resource span manually with the SDK.
+
+```javascript
+// https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming
+const resources = performance.getEntriesByType("resource");
+resources.forEach((entry) => {
+ const startTime = msToSec(entry.startTime);
+ const duration = msToSec(entry.duration);
+
+ const span = Sentry.startInactiveSpan({
+ startTimestamp: startTime,
+ op: entry.initiatorType
+ ? `resource.${entry.initiatorType}`
+ : "resource.other",
+ description: entry.name,
+ data: {
+ "http.response_transfer_size": entry.transferSize,
+ "http.response_content_length": entry.encodedBodySize,
+ "http.decoded_response_content_length": entry.decodedBodySize,
+ "resource.render_blocking_status": entry.renderBlockingStatus,
+ },
+ });
+
+ // override end timestamp to match performance entry
+ span.finish(startTime + duration);
+});
+```
+## Assets Dashboard
+
+The **Assets** dashboard gives you a quick overview of your application's asset performance for the selected project(s).
+
+Find the Assets dashboard in [Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/).
+
+At the top of the page, summary graphs for requests per minute (throughput) and average duration provide high-level insight into the performance of your assets. If you see an anomaly or want to investigate a time range further, you can click and drag to select a range directly in a graph to filter data for that time range.
+
+The asset table below shows a list of grouped assets, along with their type, their volume (requests per min), average duration, the total time your app spent loading that asset (time spent), and [average encoded size](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/encodedBodySize) of the asset.
+
+By default, the assets table is sorted by most time spent, which serves as a proxy for the relative performance impact of a given asset. An asset's time spent is the sum of all its durations in a given time period or, put another way, the product of its average duration and requests per minute. This means that assets at the top are usually loading really slowly, very frequently, or both.
+
+You can click on a column header to change how the table is sorted. Sort by requests per minute to see the most frequently loaded assets or by average duration to see the slowest-loading assets.
+
+You can also filter assets by domain, type, page it's found on, and whether it has render blocked.
+
+To view more details, click on an asset from the table to open its **Asset Summary** dashboard.
+
+
+### What Does a Render Blocking Mean?
+
+A render blocking asset is one which will stop the browser from rendering anything on the screen, until the asset is fully downloaded and processed by the browser.
+
+An example of this is a `` within the `
` of an HTML document. When loaded, the browser will want to load this script entirely before rendering content as it assumes it may need something from that script to render. If this is not the case, you can add the `defer` or `async` attribute to the script in order to reduce or eliminate render blocking.
+
+Sentry captures an asset's render blocking status using the `resource.render_blocking_status` property in the [PerformanceResourceTiming API](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/renderBlockingStatus).
+
+### Asset Parameterization
+
+To enable Sentry to group similar assets together, Sentry parameterizes asset URLs, removing potentially dynamic elements. This helps track the performance of a particular asset across different releases, even when they have dynamic segments (used for busting caches or CDNS).
+
+If you would like to further improve your groupings, consider the following rules we use when parameterizing urls. These rules can help you understand how you can name urls to improve grouping.
+
+The following tokens will be replaced with \* within a asset url
+
+1. A version string (`myfile.v3.0.js` is replaced with `myfile.*.js`)
+2. Hexadecimal strings with more than 5 digits (`myfile.7A9B3E.js` is replaced with `myfile.*.js`)
+3. UUIDs
+4. Integer IDs with more than one digit (`1234.7A9B3E.js` is replaced with `*.*.js`)
+5. Strings longer than 25 characters
+6. The entire path except for common path segments such as static, chunks, media, etc
+
+
+
+Asset parametrization is still a work-in-progress. As these improvements are made, you will temporarily see instances of the new and old groupings in your Asset Module.
+
+Let us know of any feedback through GitHub Issues.
+
+
+
+To see an example of asset URL from a group, hover over a URL in the asset table.
+
+## Asset Summary Dashboard
+
+You can open a specific asset's summary by clicking on the asset from the table in the **Assets** dashboard.
+
+Average encoded size, average decoded size, average transfer size, average duration, and requests per minute are shown for the selected time range in this dashboard. You can see summary graphs for requests per minute, average duration, and average asset size over time.
+
+You can also find a list of pages the asset is found in, sorted by the requests per minute for the asset on that page.
+
+If you want to investigate a specific page, click on it to show some sample events.
+
+
+### Image Samples
+
+When viewing an image asset, the asset summary dashboard will also show the 5 largest image samples. Sentry determines the span is an image if it has one of the following extensions: 'jpg', 'jpeg', 'png', 'gif', 'svg', 'webp', 'apng', 'avif'.
+
+If size information is not available, the samples will not be ordered in any particular order. If the images are publicly accessible and the 'Enable Images' project settings is enabled, then the actual images will be rendered in the UI.
+
+
+
+## Sample List
+
+Click on a page to open its samples list, which shows summary metrics (requests per minute, average duration, and time spent) for the selected page.
+
+The table shows a sample list of events, their span duration, and the difference in duration compared to average. This table is sorted by longest span duration.
+
+Sentry automatically finds a variety of samples to help you investigate performance problems. The chosen events cover the entire selected time range, plus a range of durations (both faster than, slower than, and near the average duration). You can get a sense of the performance characteristics by comparing different sample events.
+
+These same events are also represented as triangles shown in the average duration graph.
+
+You can generate a new list of random sample events by clicking the "Try Different Samples" button.
+
+From the sample list, you can drill down to specific good, average, or bad examples of a given asset within a given page. Click on an event ID to drill into the asset's span details within the span waterfall of the [Trace View](/concepts/key-terms/tracing/trace-view/#product-walkthrough-trace-details-page) page.
diff --git a/docs/product/dashboards/sentry-dashboards/frontend/index.mdx b/docs/product/dashboards/sentry-dashboards/frontend/index.mdx
new file mode 100644
index 0000000000000..2a90933b5f1a8
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/frontend/index.mdx
@@ -0,0 +1,22 @@
+---
+title: Frontend Dashboards
+sidebar_order: 10
+description: >-
+ Learn how to use Sentry's Frontend dashboards to monitor things like web
+ vitals and network requests.
+og_image: /og-images/product-insights-frontend.png
+---
+
+Sentry's Frontend dashboards give you an overview of the health of your application.
+
+## Frontend Overview
+
+Start with the **Frontend Overview** dashboard to get a quick overview of the health of your application. See things like **Best Page Opportunities** (the improvements that would most help increase your performance score), your **Most Time-Consuming Assets**, **p50** and **p75 Duration**, and so on.
+
+
+
+You can also dive deeper into Web Vitals, Network Requests, and Assets to get detailed information about potential issues affecting your application's health.
+
+## Learn More
+
+
diff --git a/docs/product/dashboards/sentry-dashboards/frontend/session-health.mdx b/docs/product/dashboards/sentry-dashboards/frontend/session-health.mdx
new file mode 100644
index 0000000000000..99fcf85e44853
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/frontend/session-health.mdx
@@ -0,0 +1,34 @@
+---
+title: Session Health
+sidebar_order: 30
+description: "Get insights about your application's session health over time."
+---
+
+
+
+## Charts
+
+
+
+The following charts are available:
+
+- Unhealthy Sessions
+- Session Health
+- Session Counts
+- User Health
+- User Counts
+- [Issues](/product/issues/)
+
+Most of these charts, with the exception of the Issues chart, are based on sessions-backed data.
+
+The Session Health, Session Counts, User Health, and User Counts charts aim to break down trends in how your sessions are performing status-wise. The status options are healthy, crashed, errored, or abnormal. For frontend sessions, the "errored" status refers to handled errors, and "crashed" refers to unhandled errors. Note that these are mutually exclusive groups. [Learn more about session statuses](/product/releases/health/#session-status).
+
+The **Unhealthy Sessions** chart combines the total rate of errored, crashed, and abnormal sessions into one line.
+
+The **Issues** chart shows the number of new and resolved issues for the selected projects over time. It also gives a preview of the two most recently seen issues for the selected projects. The chart header, when hovered, has a button to view all issues for the selected projects.
+
+Click on any series option in the graph legend to hide it. In some charts, including the Session Health chart, the healthy series is hidden by default to allow you to automatically see the errored, abnormal, and crashed series at a better scale.
+
+The overall chart view can be customized, so that you can display the visualizations and metrics you care about most. Simply click the toggle near the chart title to see other charts that can be displayed.
+
+You can customize this dashboard by updating filters or duplicating it to create a new dashboard.
diff --git a/docs/product/dashboards/sentry-dashboards/frontend/web-vitals/index.mdx b/docs/product/dashboards/sentry-dashboards/frontend/web-vitals/index.mdx
new file mode 100644
index 0000000000000..2b7641855b579
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/frontend/web-vitals/index.mdx
@@ -0,0 +1,99 @@
+---
+title: "Web Vitals"
+sidebar_order: 0
+description: "Get a clear picture of your app's Performance Score and how each Web Vital shapes it. Then, learn how to drill in to explore opportunities to improve your app's overall performance."
+---
+
+Web vitals are a set of key metrics that measure how users actually experience your site; these include load speed, responsiveness and visual stability. [Learn more about these metrics in Web Vitals Concepts](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/).
+
+For your instrumented web apps, Sentry gathers Web Vitals from real user traffic across [supported browsers](web-vitals-concepts/#browser-support). These metrics are used to calculate a [Performance Score](#performance-score) for your web application. Using these metrics, we surface the pages that have the most [opportunity](#opportunity) to improve your app's overall performance.
+
+{/* The interactive demo below walks through how to get insights on your Web Vitals. */}
+
+
+
+## Web Vitals Dashboard
+
+The **Web Vitals** dashboard, found in [Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/), gives you an overview of your page load and interaction performance for the selected project(s). It's a starting point for investigating poor Web Vitals affecting your web app and drilling down to better understand which pages are affecting your web performance the most.
+
+The [Performance Score](#performance-score) ring shows the overall performance rating of your application. Each component of the ring represents a single Web Vital and its relative weight and impact on the Performance Score. The area chart shows you a breakdown, by Web Vitals, of your Performance Score over time, making it easy to spot which metrics are improving or slipping.
+
+Below this, you can see your app's p75 (75th percentile) vital values and the individual scores for each Web Vital. These highlight which Web Vitals need the most attention. Clicking on any Web Vital opens a more detailed summary of that metric and reveals which pages have the most [opportunity](#opportunity) for improvement.
+
+At the bottom of the page, a sortable table lists all of your app's pages, along with their associated p75 values for each Web Vital and their individual Performance Scores. The Opportunity column displays a page score's potential improvement to your application's overall Performance Score if maximized to 100. The search bar above this table allows you to filter for specific pages by route name.
+
+
+
+The **Web Vitals** page only displays data from your application's initial page load transactions and interactions. Navigations are **not** included.
+
+
+
+## Page Summary
+
+From the table in **Web Vitals** or a Web Vital Summary panel, click on a page to open its **Page Summary**. Here, you can see a summary of that single page's Web Vitals. In **Page Summary**, you can further drill down to a specific page load sample [Trace](/concepts/key-terms/tracing/#whats-a-trace), [LCP Element](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#largest-contentful-paint-lcp), [Replay](/product/explore/session-replay/), or [Profile](/product/explore/profiling/). The page's Performance Score is represented in a circular graph broken down by metric, as well as a "Page Loads" chart.
+
+### Samples List
+
+
+ The samples list only shows page loads with Web Vitals and Performance Score.
+ If a page load is missing a required Web Vital, it will not be shown in the
+ samples list. Find out which Web Vitals are required in the [Browser
+ Support](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#browser-support)
+ table.
+
+
+In the **Page Summary**, Web Vital p75 values and scores are displayed. Clicking a Web Vital score will open details containing a variety of **Page Load** samples with good to poor scores. Each sample contains a Trace ID that can be clicked to open the [Trace View](/concepts/key-terms/tracing/trace-view/#product-walkthrough-trace-details-page) page for further investigation. If there is a [Replay](/product/session-replay/) or [Profile](/product/profiling/) associated with the sample page load, links to those will be included.
+
+## Performance Score
+
+**Performance Score** is a rating from 0 to 100 that summarizes the perceived performance of your web app, based on **Web Vitals**. Each **Web Vital** is given a rating from 0 to 100 through a [Log-Normal Distribution](https://www.desmos.com/calculator/o98tbeyt1t), which is then weighed and aggregated by page and overall for your entire web application.
+
+**Page Loads** can have up to 4 individual **Web Vital** components that can be found on each event, while interactions contribute to **INP** (Interaction to Next Paint). The default weight and score-rating thresholds for each **Web Vital** can be found in the tables below.
+
+**Desktop Browsers**:
+| Web Vital | Good (90+) | Meh (50+) | Weight |
+| --------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------ | ------ |
+| [Largest Contentful Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#largest-contentful-paint-lcp) (LCP) | [1200ms](https://www.desmos.com/calculator/ejhjazajbd) | [2400ms](https://www.desmos.com/calculator/ejhjazajbd) | 30% |
+| [Cumulative Layout Shift](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#cumulative-layout-shift-cls) (CLS) | [0.1](https://www.desmos.com/calculator/irdoqfftdf) | [0.25](https://www.desmos.com/calculator/irdoqfftdf) | 15% |
+| [First Contentful Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#first-contentful-paint-fcp) (FCP) | [900ms](https://www.desmos.com/calculator/gcxbiypuuh) | [1600ms](https://www.desmos.com/calculator/gcxbiypuuh) | 15% |
+| [Time To First Byte](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#time-to-first-byte-ttfb) (TTFB) | [200ms](https://www.desmos.com/calculator/ykzahw9goi) | [400ms](https://www.desmos.com/calculator/ykzahw9goi) | 10% |
+| [Interaction to Next Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#interaction-to-next-paint-inp) (INP) | [200ms](https://www.desmos.com/calculator/jaqxodpx8d) | [500ms](https://www.desmos.com/calculator/jaqxodpx8d) | 30% |
+
+**Mobile Browsers**:
+| Web Vital | Good (90+) | Meh (50+) | Weight |
+| --------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------ | ------ |
+| [Largest Contentful Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#largest-contentful-paint-lcp) (LCP) | [2500ms](https://www.desmos.com/calculator/tegmkln1hr) | [4000ms](https://www.desmos.com/calculator/tegmkln1hr) | 30% |
+| [Cumulative Layout Shift](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#cumulative-layout-shift-cls) (CLS) | [0.1](https://www.desmos.com/calculator/irdoqfftdf) | [0.25](https://www.desmos.com/calculator/irdoqfftdf) | 15% |
+| [First Contentful Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#first-contentful-paint-fcp) (FCP) | [1800ms](https://www.desmos.com/calculator/ezkvtlqxkf) | [3000ms](https://www.desmos.com/calculator/ezkvtlqxkf) | 15% |
+| [Time To First Byte](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#time-to-first-byte-ttfb) (TTFB) | [800ms](https://www.desmos.com/calculator/xcpjhfvwfo) | [1800ms](https://www.desmos.com/calculator/xcpjhfvwfo) | 10% |
+| [Interaction to Next Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#interaction-to-next-paint-inp) (INP) | [200ms](https://www.desmos.com/calculator/jaqxodpx8d) | [500ms](https://www.desmos.com/calculator/jaqxodpx8d) | 30% |
+
+
+These thresholds are meant to match Google Lighthouse as closely as possible, but there may be some differences because Sentry operates on real user data, whereas Google Lighthouse operates on lab data.
+
+Some browsers may not support all **Web Vitals** used in Sentry's **Performance Score** calculation. Look at the [Browser Support](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#browser-support) table to see which Web Vitals are supported by your browser.
+
+
+
+## Opportunity
+
+**Opportunity** scores are number values associated with each page and are meant to give you a sense of which pages are most valuable to improve. The Opportunity score is the maximum possible increase to your application's overall Performance Score if you were to raise a page's score to 100. If a page in your application already has a score of 100, the Opportunity score would be 0, since there's no way to further optimize this page.
+
+Opportunity score calculation is also weighted based on the traffic that a page sees. Pages with high traffic tend to have higher Opportunity scores. For example, a page with a score of 70 that experiences 1000 page loads a day will have a higher Opportunity score than a page with a score of 50 that experiences only 10 page loads a day.
+
+### Prerequisites and Limitations
+
+**Web Vitals** and **Performance Scores** are automatically captured by Sentry's JavaScript SDKs through the [BrowserTracing](/platforms/javascript/configuration/integrations/browsertracing/) integration.
+
+You can find out how to set up Sentry on your web application in the [installation docs](/platforms/javascript/). If you are using a JavaScript framework, you may need to follow additional setup instructions for your specific framework:
+
+- [React SDK](/platforms/javascript/guides/react/)
+- [Vue SDK](/platforms/javascript/guides/vue/)
+- [Angular SDK](/platforms/javascript/guides/angular/)
+- [Svelte SDK](/platforms/javascript/guides/svelte/)
+
+Although Sentry provides auto instrumentation for many frontend frameworks, there are some environments and scenarios that may not be fully supported. If you are unable to find your pages in the **Web Vitals** page, check to see if your page loads are meeting the following conditions:
+
+- **Performance Scores** only support **Chrome**, **Firefox**, **Safari**, **Opera**, and **Edge** desktop and mobile browsers.
+- Some pageloads may not capture all Web Vitals supported by Sentry. This may depend on the client browser and/or the unique behavior of your web page.
+ - Find out the full list of Web Vitals in the [Browser Support](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#browser-support) table.
diff --git a/docs/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts.mdx b/docs/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts.mdx
new file mode 100644
index 0000000000000..11cb6f570ea7e
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts.mdx
@@ -0,0 +1,104 @@
+---
+title: Web Vitals Concepts
+sidebar_order: 10
+description: >-
+ Learn more about web vitals and how each metric relates to your application's
+ performance.
+og_image: /og-images/product-insights-frontend-web-vitals-web-vitals-concepts.png
+---
+
+[Web Vitals](https://web.dev/vitals/) are a set of metrics defined by Google to measure render time, response time, and layout shift. Each data point provides insights about the overall [performance](/product/dashboards/sentry-dashboards/) of your application.
+
+The in-browser Sentry SDKs collect web vitals information (where supported) and adds that information to frontend [transactions](/product/dashboards/sentry-dashboards/transaction-summary/). These web vitals are then summarized in the [Web Vitals dashboard](/product/dashboards/sentry-dashboards/frontend/web-vitals/) to give you a quick overview of how each page is performing for your users.
+
+
+
+## Core Web Vitals
+
+Google considers Core Web Vitals to be the most important metrics for measuring the user experience on web pages. According to a May 2021 [Google blog post](https://developers.google.com/search/blog/2020/11/timing-for-page-experience), these metrics also impact your search ranking.
+
+### Largest Contentful Paint (LCP)
+
+[Largest Contentful Paint (LCP)](https://web.dev/lcp/) measures how long it takes for the content that covers the largest pixel area in the viewport to render - in other words, how long before a user sees the main content on a page. This content may take any form from the document object model (DOM), such as an image, SVG, or text block.
+
+### Interaction to Next Paint (INP)
+
+
+On March 12, 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital. Prior to this, INP was an experimental metric that Sentry did not collect. To begin collecting INP measurements, make sure your JavaScript SDK version is [7.104.0](https://github.com/getsentry/sentry-javascript/releases/tag/7.104.0) or higher and that the option [`enableInp`](/platforms/javascript/tracing/instrumentation/automatic-instrumentation/#enableinp) is on (starting with version `8.0.0`, `enableInp` is enabled by default).
+
+
+[Interaction to Next Paint (INP)](https://web.dev/articles/inp) measures the time from when a user interacts with a page (through a click, tap, or keyboard input) to when the next paint (rendering of content on the screen) occurs. INP aims to assess how quickly users see a response from the website after taking an action, which is crucial for providing a smooth and responsive user experience.
+
+### Cumulative Layout Shift (CLS)
+
+[Cumulative Layout Shift (CLS)](https://web.dev/cls/) is the sum of individual layout shift scores for every unexpected element shift that happens during the rendering process. An example of this would be trying to click a link on a page that hasn't finished loading and having that link shift down before you've had a chance to click on it due to image rendering issues. The CLS web vital score isn't based on duration. It represents the extent of the disruptive and visually unstable shifts.
+
+
+
+Each layout shift score is calculated using an impact and distance fraction. The impact fraction is the total visible area that the element affects between the two rendered frames. The distance fraction measures the distance it has moved relative to the viewport.
+
+```
+Layout Shift Score = Impact Fraction * Distance Fraction
+```
+
+Let's take a look at the example above which has one unstable element - the body text. The impact fraction is roughly 50% of the page and moves the body text down by 20%. The layout shift score is 0.1, the product of 0.5\*0.2. Thus, CLS is 0.1.
+
+## Other Web Vitals
+
+These Web Vitals are generally less user-visible, but are useful for troubleshooting issues with the Core Web Vitals.
+
+### First Paint (FP)
+
+First Paint (FP) measures the amount of time the first pixel takes to appear in the viewport, rendering any visual change from what was previously displayed. This may be in any form from the document object model (DOM), such as background color, canvas, or image. FP helps developers understand if anything unexpected is happening to render the page.
+
+### First Contentful Paint (FCP)
+
+[First Contentful Paint (FCP)](https://web.dev/fcp/) measures the time for the first content to render in the viewport. This may be in any form from the document object model (DOM), such as images, SVGs, or text blocks. FCP frequently overlaps with First Paint (FP). FCP helps developers understand how long it takes before the user sees any content change on the page.
+
+### Time To First Byte (TTFB)
+
+[Time To First Byte (TTFB)](https://web.dev/articles/ttfb) measures the time that it takes for a user's browser to receive the first byte of page content. TTFB helps developers understand whether their slowness is caused by the initial response or instead due to render-blocking content.
+
+### First Input Delay (FID)
+
+
+As of March 12, 2024, First Input Delay (FID) was replaced as a Core Web Vital by INP. While Sentry no longer includes FID in our performance score calculations nor on the **Web Vitals** performance page, we continue to collect FID metrics. You can query FID measurements in [Discover](/product/explore/discover-queries/).
+
+
+[First Input Delay (FID)](https://web.dev/fid/) measures response time when a user tries to interact with the viewport by clicking a button, link, or any other custom JavaScript controller. FID data is critical for understanding whether interactions on an application page are successful or not.
+
+
+## Thresholds
+
+Google's "Good", "Needs Improvement", and "Poor" thresholds are used to classify data points into green, yellow, and red for the corresponding Web Vitals. "Needs improvement" is referred to as "Meh" in Sentry.
+
+| Web Vital | Good | Meh | Poor |
+| --------------------------------------------------------------- | -------- | -------- | ------- |
+| [Largest Contentful Paint](#largest-contentful-paint-lcp) (LCP) | <= 2.5s | <= 4s | > 4s |
+| [Interaction to Next Paint](#interaction-to-next-paint-inp) (INP)| <= 200ms | <= 500ms | > 500ms |
+| [Cumulative Layout Shift](#cumulative-layout-shift-cls) (CLS) | <= 0.1 | <= 0.25 | > 0.25 |
+| [First Paint](#first-paint-fp) (FP) | <= 1s | <= 3s | > 3s |
+| [First Contentful Paint](#first-contentful-paint-fcp) (FCP) | <= 1s | <= 3s | > 3s |
+| [Time To First Byte](#time-to-first-byte-ttfb) (TTFB) | <= 100ms | <= 200ms | > 600ms |
+| [First Input Delay](#first-input-delay-fid) (FID) | <= 100ms | <= 300ms | > 300ms |
+
+
+
+Some Web Vitals such as FP, FCP, LCP, and TTFB are measured relative to the start of the transaction. Values may differ when compared to values generated with other tools such as [Lighthouse](https://github.com/GoogleChrome/lighthouse).
+
+
+
+
+## Browser Support
+
+Not all browsers fully support all web vitals. Sentry uses available web vitals to calculate [Performance Score](/product/dashboards/sentry-dashboards/frontend/web-vitals/#performance-score).
+
+| Web Vital | Chrome | Edge | Opera | Firefox | Safari |
+| ----------------------------------------------------------------- | ------ | ---- | ----- | ------- | ------ |
+| [Largest Contentful Paint](#largest-contentful-paint-lcp) (LCP) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [Interaction to Next Paint](#interaction-to-next-paint-inp) (INP) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [Cumulative Layout Shift](#cumulative-layout-shift-cls) (CLS) | ✓ | ✓ | ✓ | | |
+| [First Paint](#first-paint-fp) (FP) | ✓ | ✓ | ✓ | | |
+| [Time To First Byte](#time-to-first-byte-ttfb) (TTFB) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [First Contentful Paint](#first-contentful-paint-fcp) (FCP) | ✓ | ✓ | ✓ | ✓ | ✓ |
+| [First Input Delay](#first-input-delay-fid) (FID) | ✓ | ✓ | ✓ | ✓ | |
diff --git a/docs/product/dashboards/sentry-dashboards/img/01_full_widget_all.png b/docs/product/dashboards/sentry-dashboards/img/01_full_widget_all.png
new file mode 100644
index 0000000000000..ab6d8bc397f0f
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/01_full_widget_all.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/asset-sample-images.png b/docs/product/dashboards/sentry-dashboards/img/asset-sample-images.png
new file mode 100644
index 0000000000000..8aeac746a25e5
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/asset-sample-images.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/backend-performance-overview.png b/docs/product/dashboards/sentry-dashboards/img/backend-performance-overview.png
new file mode 100644
index 0000000000000..06fb970a2f00c
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/backend-performance-overview.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/caches-dash.png b/docs/product/dashboards/sentry-dashboards/img/caches-dash.png
new file mode 100644
index 0000000000000..24beb030dec9b
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/caches-dash.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/custom-metrics-performance.png b/docs/product/dashboards/sentry-dashboards/img/custom-metrics-performance.png
new file mode 100644
index 0000000000000..ea2b39514b210
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/custom-metrics-performance.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/diagram-transaction-cls.png b/docs/product/dashboards/sentry-dashboards/img/diagram-transaction-cls.png
new file mode 100644
index 0000000000000..3a117554f831b
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/diagram-transaction-cls.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/diagram-transaction-vitals.png b/docs/product/dashboards/sentry-dashboards/img/diagram-transaction-vitals.png
new file mode 100644
index 0000000000000..88bb73a5599a6
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/diagram-transaction-vitals.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/exclusive-time.png b/docs/product/dashboards/sentry-dashboards/img/exclusive-time.png
new file mode 100644
index 0000000000000..d60835f3bd2c4
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/exclusive-time.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/frontend-asset.png b/docs/product/dashboards/sentry-dashboards/img/frontend-asset.png
new file mode 100644
index 0000000000000..9a1e1c0ef5da6
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/frontend-asset.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/frontend-overview-dash.png b/docs/product/dashboards/sentry-dashboards/img/frontend-overview-dash.png
new file mode 100644
index 0000000000000..a8f013f696427
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/frontend-overview-dash.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/frontend-performance-overview.png b/docs/product/dashboards/sentry-dashboards/img/frontend-performance-overview.png
new file mode 100644
index 0000000000000..efe381a96d683
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/frontend-performance-overview.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/frontend-session-health.png b/docs/product/dashboards/sentry-dashboards/img/frontend-session-health.png
new file mode 100644
index 0000000000000..1afa834137d6e
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/frontend-session-health.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/mobile-performance-overview.png b/docs/product/dashboards/sentry-dashboards/img/mobile-performance-overview.png
new file mode 100644
index 0000000000000..0202f4907fd11
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/mobile-performance-overview.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/mobile-session-health-dash.png b/docs/product/dashboards/sentry-dashboards/img/mobile-session-health-dash.png
new file mode 100644
index 0000000000000..819549ad3728f
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/mobile-session-health-dash.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/queries-dash.png b/docs/product/dashboards/sentry-dashboards/img/queries-dash.png
new file mode 100644
index 0000000000000..e64596df4372d
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/queries-dash.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/query-source-laravel.png b/docs/product/dashboards/sentry-dashboards/img/query-source-laravel.png
new file mode 100644
index 0000000000000..24aa8a083020d
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/query-source-laravel.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/resource-sample-images.png b/docs/product/dashboards/sentry-dashboards/img/resource-sample-images.png
new file mode 100644
index 0000000000000..b2fedbce349fc
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/resource-sample-images.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/tags.png b/docs/product/dashboards/sentry-dashboards/img/tags.png
new file mode 100644
index 0000000000000..41670c15ce612
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/tags.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/transaction-summary.png b/docs/product/dashboards/sentry-dashboards/img/transaction-summary.png
new file mode 100644
index 0000000000000..4598d03a45763
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/transaction-summary.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/trends.png b/docs/product/dashboards/sentry-dashboards/img/trends.png
new file mode 100644
index 0000000000000..d7c2ee7331aa9
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/trends.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/img/web-vitals-overview.png b/docs/product/dashboards/sentry-dashboards/img/web-vitals-overview.png
new file mode 100644
index 0000000000000..c83c7d50e5d6e
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/img/web-vitals-overview.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/index.mdx b/docs/product/dashboards/sentry-dashboards/index.mdx
new file mode 100644
index 0000000000000..2373ab01c65d3
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/index.mdx
@@ -0,0 +1,90 @@
+---
+title: Sentry Dashboards
+sidebar_order: 45
+description: >-
+ Learn how Sentry's out-of-the-box dashboards for frontend, backend, mobile, and AI give you an overview of the health of your application.
+og_image: /og-images/product-insights-overview.png
+---
+
+Spot trends, fix issues, and boost application performance with Sentry's frontend, backend, mobile, and AI performance dashboards in [**Sentry Dashboards**](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/). Get a summary of the telemetry and events impacting the performance of your application, like web vitals, crash rate, session health, and outbound API requests. You can also use it to drill deeper into specific workflows and review traces, errors, and releases.
+
+Sentry Dashboards use [tracing data](/concepts/key-terms/tracing/). By enabling tracing, Sentry tracks application performance, measuring metrics like throughput and latency, displaying the impact of errors across multiple services. Sentry captures [distributed traces](/product/sentry-basics/tracing/distributed-tracing/) consisting of multiple [spans](/product/explore/trace-explorer/#spans) to measure individual services and operations within those services.
+
+Haven't set it up yet? Use the SDK to [set up tracing for your platform](/platform-redirect/?next=%2Ftracing%2F).
+
+## Sentry Dashboards Overview
+
+Sentry Dashboards cannot be edited, but they can be duplicated to create a [custom dashboard](/product/dashboards/custom-dashboards/).
+
+Like all dashboards, Sentry Dashboards can be [filtered](/product/dashboards/index/#global-filters) to focus on the data that's most important to you. Environment, project, date range, release, as well as custom filters from data sets like spans, errors, and logs can be used.
+
+### Types of Dashboards
+
+Sentry comes with the following dashboards. For AI monitoring, see [AI Dashboards](/ai/monitoring/dashboards/).
+
+#### App-Wide Dashboards
+
+| Dashboard | Description |
+|-----------|-------------|
+| **Outbound API Requests** | Monitors all outgoing HTTP requests and the domains that serve them: average response duration and rate of 3xx, 4xx, and 5xx status codes. [Learn more](/product/dashboards/sentry-dashboards/outbound-api-requests/) |
+| **Domain Details** | Drill-down view for a single outbound HTTP domain (throughput, average duration, response code breakdowns). Linked from Outbound API Requests when you click a domain. |
+
+#### Frontend Dashboards
+
+| Dashboard | Description |
+|-----------|-------------|
+| **Frontend Overview** | Search or browse transaction data (page loads, navigations, async tasks). Trace performance across services and see how releases and services are performing. [Learn more](/product/dashboards/sentry-dashboards/frontend/) |
+| **Frontend Session Health** | Charts for healthy vs. crashed/errored session rates and new issues per release. Connect deployments to session health and prioritize fixes by user impact. [Learn more](/product/dashboards/sentry-dashboards/frontend/session-health/) |
+| **Web Vitals** | Real user metrics across supported browsers; Performance Score and pages with the most opportunity to improve. [Learn more](/product/dashboards/sentry-dashboards/frontend/web-vitals/) |
+| **Web Vitals Page Summary** | Drill-down from Web Vitals for a single page: p75 for LCP, INP, CLS, TTFB, performance score breakdown, and sample page loads. |
+| **Frontend Assets and Summary** | All assets your site loads with duration and size; throughput and average duration. Pinpoint slow or render-blocking assets and drill into asset summary pages. |
+
+#### Backend Dashboards
+
+| Dashboard | Description |
+|-----------|-------------|
+| **Backend Overview** | Health of your backend: Most Time-Consuming Queries and Domains, p50/p75 duration. Entry point for Queries, Outbound API Requests, Caches, and Queues. |
+| **Queries and Query Details** | Database query performance: throughput, average duration, and drill-down to a query's summary and sample events. [Learn more](/product/dashboards/sentry-dashboards/backend/queries/) |
+| **Caches** | Cache hit/miss rates, throughput, and latency. Identify transactions with poor cache interaction and drill into span operations. [Learn more](/product/dashboards/sentry-dashboards/backend/caches/) |
+| **Queue Summary and Queues** | Message queue metrics: publish and processing latency, error rates, throughput. Spot queue health issues and drill into specific destinations. [Learn more](/product/dashboards/sentry-dashboards/backend/queues/) |
+
+#### Mobile Dashboards
+
+| Dashboard | Description |
+|-----------|-------------|
+| **Mobile Vitals** | Overview of screen performance: cold/warm app starts, slow and frozen frame rates, TTID/TTFD. Opinionated scores similar to Web Vitals. [Learn more](/product/dashboards/sentry-dashboards/mobile/mobile-vitals/) |
+| **Mobile Session Health** | Crash-free session and user rates over time with release annotations; correlate deployments with crashes, ANRs, unhealthy sessions. iOS and Android. [Learn more](/product/dashboards/sentry-dashboards/mobile/mobile-session-health/) |
+| **Mobile Vitals App Starts** | Cold and warm start times; identify slow or regressed starts and factors contributing to slowness. [Learn more](/product/dashboards/sentry-dashboards/mobile/mobile-vitals/app-starts/) |
+| **Mobile Vitals Screen Rendering** | Frame rendering: slow frames (>16.7ms), frozen frames (>700ms), frame delay. Find screens where the UI feels laggy or unresponsive. |
+| **Mobile Vitals Screen Loads** | TTID and TTFD across screens; identify slowest-loading screens and drill into traces and CPU profiles. [Learn more](/product/dashboards/sentry-dashboards/mobile/mobile-vitals/screen-loads/) |
+
+#### Framework-Specific Dashboards
+
+| Dashboard | Description |
+|-----------|-------------|
+| **Next.js Overview** | Holistic view for Next.js: traffic, performance, client- and server-side issues, Web Vitals, rage & dead clicks. Tree-based SSR view for performance bottlenecks. |
+| **Laravel Overview** | Backend performance, error rates, and request throughput for Laravel. Metrics most relevant to Laravel developers out of the box. |
+
+## Investigate
+
+### Transactions
+
+When you find a transaction of interest, you can investigate further by going to its [Transaction Summary page](/product/dashboards/sentry-dashboards/transaction-summary/). Every transaction has a summary view that gives you a better understanding of its overall health. With this view, you'll find graphs, instances of these events, stats, facet maps, related errors, and more.
+
+The summary page for Frontend transactions links out to the web vitals page, where you can see a detailed view of the [Web Vitals](/product/dashboards/sentry-dashboards/frontend/web-vitals/) associated with the transaction. You can also access a **Transaction Summary** page from the transactions table on the **Performance** page.
+
+### Performance Metrics
+
+There are several types of [metrics](/product/dashboards/sentry-dashboards/transaction-summary/#metrics-in-this-view) that you can visualize in the graphs, such as Apdex, Transactions Per Minute, P50 Duration, and User Misery to get a full understanding of how your software is performing.
+
+### Triage Performance Issues
+
+If your application is configured with tracing, Sentry will detect common performance problems, and group them into issues just like it does with errors. Performance issues help to surface performance problems in your application and provide a workflow for resolving them. Learn more about [performance issues](/product/issues/issue-details/performance-issues/).
+
+## Dynamic Sampling
+
+Depending on your plan, the data ingested into Sentry may be affected by [Dynamic Sampling](/organization/dynamic-sampling/).
+
+## Learn More
+
+
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/index.mdx b/docs/product/dashboards/sentry-dashboards/mobile/index.mdx
new file mode 100644
index 0000000000000..2ffb6eb796ced
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/mobile/index.mdx
@@ -0,0 +1,16 @@
+---
+title: Mobile Dashboards
+sidebar_order: 30
+description: >-
+ Learn how to use Sentry's Mobile Performance dashboard to monitor the health of
+ your mobile app, including app starts, screen loads, and screen rendering.
+og_image: /og-images/product-insights-mobile.png
+---
+
+The Mobile Dashboard found on [Sentry Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/) gives an overview of the metrics that let you know how fast your app starts, including the number of slow and frozen frames your users may be experiencing. Each metric provides insights into the overall performance health of your mobile application. Digging into the details helps prioritize critical performance issues and allows you to identify and troubleshoot the root cause faster.
+
+{/**/}
+
+## Learn More
+
+
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/app-starts.mdx b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/app-starts.mdx
new file mode 100644
index 0000000000000..a9d2e9b736b73
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/app-starts.mdx
@@ -0,0 +1,91 @@
+---
+title: App Starts
+sidebar_order: 20
+description: >-
+ Learn how to monitor your mobile application's performance by using App Starts
+ to identify slow or regressed screens.
+og_image: /og-images/product-insights-mobile-mobile-vitals-app-starts.png
+---
+
+
+
+The **App Starts** dashboard in [Sentry Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/) shows an overview of the amount of time it takes for your application to complete cold and warm starts. It helps you identify slow or regressed screens and gives additional information so you can better understand the factors contributing to the slowness of your application start times.
+
+### Minimum SDK Requirements:
+
+**For Android:**
+
+- `>=7.4.0` for automatic instrumentation of app start spans and app start profiling
+- [Performance-V2](/platforms/android/performance/instrumentation/perf-v2) feature flag (`<8.0.0`) and [App Start Profiling](/platforms/android/profiling/#app-start-profiling) must also be enabled in the SDK, e.g.:
+
+```java {filename:MyApplication.java}
+import io.sentry.android.core.SentryAndroid;
+
+SentryAndroid.init(this, options -> {
+ options.setEnablePerformanceV2(true);
+ options.setEnableAppStartProfiling(true);
+});
+```
+
+```kotlin {filename:MyApplication.kt}
+import io.sentry.android.core.SentryAndroid
+
+SentryAndroid.init(this) { options ->
+ options.enablePerformanceV2 = true
+ options.enableAppStartProfiling = true;
+}
+```
+
+```xml {filename:AndroidManifest.xml}
+
+
+
+
+
+
+```
+
+**For iOS:**
+
+- `>=7.2.0` for automatic instrumentation of [app start spans](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#app-start-tracing)
+- `>=8.21.0` for app start profiling
+
+**For React Native:**
+
+- `>=5.24.0` for automatic instrumentation of [app start spans](/platforms/react-native/tracing/instrumentation/automatic-instrumentation/#app-start-instrumentation)
+
+By default, the **App Starts** dashboard displays metrics for the two releases with the highest screen counts for the time range you've selected. To choose a different set of releases to compare, use the "release selector" at the top of the dashboard. To change the app start type (cold or warm), use the "App Start" selector at the top of the dashboard.
+
+The charts display the following metrics (using cold starts as an example):
+
+- Average Cold Start
+ - The overall time it takes your application to start, compared by release.
+- Cold Start Device Distribution
+ - The average cold start time grouped by [device class](/concepts/search/searchable-properties/#device-classification) (high, medium, low, or unknown).
+
+**Reasons Why You Might Not Be Seeing Any Data:**
+
+- You don't have any transactions with op `ui.load`
+- Your SDKs don't meet the minimum SDK requirements
+
+The table at the bottom shows spans that have changed from one release to the next and allows you to filter for specific span operations and device classes. Being able to narrow down to specific event samples helps debug slow starts.
+
+Clicking the "By Event" toggle in the top right corner of this table will show you events split by release and you'll be able to see overall changes in start times between the two releases you've selected.
+
+
+
+The following table describes the span operations that are surfaced in the spans table:
+
+| Platform | Span Operations |
+| --- | --- |
+| Common | - file.write
- ui.load
- http.client
- db
- db.sql.query
- db.sql.transaction
|
+| [iOS](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#app-start-tracing) | - app.start.cold
- app.start.warm
|
+| Android | - activity.load
- application.load
- contentprovider.load
- process.load
|
+
+## Span Detail View
+
+
+
+Clicking on a span description opens up the Traces page, where you can see sampled spans.
+
+In the table, you'll see a list of sampled spans. Click into one to get a waterfall view of the span.
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/01_full_widget_mobile.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/01_full_widget_mobile.png
new file mode 100644
index 0000000000000..e40e9a137be81
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/01_full_widget_mobile.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-start-transaction.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-start-transaction.png
new file mode 100644
index 0000000000000..dbb863ee822b1
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-start-transaction.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts-samples-by-event.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts-samples-by-event.png
new file mode 100644
index 0000000000000..7d24d2c742e8a
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts-samples-by-event.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts-span-detail-view.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts-span-detail-view.png
new file mode 100644
index 0000000000000..c57023498fe7e
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts-span-detail-view.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts.png
new file mode 100644
index 0000000000000..fb966ed0f826e
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/app-starts.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-screen-load-example.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-screen-load-example.png
new file mode 100644
index 0000000000000..adeb134ac23aa
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-screen-load-example.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-vitals-dash.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-vitals-dash.png
new file mode 100644
index 0000000000000..ce977a4fc9d1b
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-vitals-dash.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-vitals.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-vitals.png
new file mode 100644
index 0000000000000..7bc209ebc6d4f
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-vitals.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-warm-start.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-warm-start.png
new file mode 100644
index 0000000000000..d98d9e6d411bf
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/mobile-warm-start.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/screen-loads-span-detail.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/screen-loads-span-detail.png
new file mode 100644
index 0000000000000..3ac1a0b12d36a
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/screen-loads-span-detail.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/screen-loads.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/screen-loads.png
new file mode 100644
index 0000000000000..12aa025c1df97
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/screen-loads.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/slow-frozen-frames.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/slow-frozen-frames.png
new file mode 100644
index 0000000000000..ce27391eee6c2
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/slow-frozen-frames.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/slow-ios-span.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/slow-ios-span.png
new file mode 100644
index 0000000000000..f537937e91cf1
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/slow-ios-span.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/time-to-initial-full-display.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/time-to-initial-full-display.png
new file mode 100644
index 0000000000000..1daed1d8547a5
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/time-to-initial-full-display.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/time-to-initial-mobile.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/time-to-initial-mobile.png
new file mode 100644
index 0000000000000..d7e5b450ed1f6
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/time-to-initial-mobile.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/ttid-ttfd-affecting-spans.png b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/ttid-ttfd-affecting-spans.png
new file mode 100644
index 0000000000000..9c880653ca8be
Binary files /dev/null and b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/img/ttid-ttfd-affecting-spans.png differ
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/index.mdx b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/index.mdx
new file mode 100644
index 0000000000000..19142cb608451
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/index.mdx
@@ -0,0 +1,106 @@
+---
+title: Mobile Vitals
+sidebar_order: 0
+description: Track the performance of your app.
+og_image: /og-images/product-insights-mobile-mobile-vitals.png
+---
+
+The Mobile Vitals dashboard, found in [Sentry Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/) provides a high-level overview of the performance of your screens, and allows you to drill down into the performance metrics of individual screens.
+
+
+
+## App Start
+
+App start metrics track how long your mobile application takes to launch. For this, Sentry measures [_cold starts_]( /concepts/search/searchable-properties/events/#measurementsapp_start_cold) and [_warm starts_](/concepts/search/searchable-properties/events/#measurementsapp_start_warm).
+
+The definitions of cold start and warm start change slightly depending on the operating system. On iOS, Apple recommends your app take at most 400ms to render the first frame. On Android, the [Google Play console](https://developer.android.com/topic/performance/vitals/launch-time#av) warns you when a cold start takes longer than five seconds or a warm start longer than two seconds. For definitions by operating system, check out the corresponding SDK docs:
+
+- [Android](/platforms/android/tracing/instrumentation/automatic-instrumentation/#app-start-instrumentation)
+- [Apple](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#app-start-tracking)
+- [Flutter](/platforms/dart/guides/flutter/tracing/instrumentation/automatic-instrumentation/#app-start-instrumentation)
+- [React Native](/platforms/react-native/tracing/instrumentation/automatic-instrumentation/#app-start-instrumentation)
+
+
+
+Sentry's App Start instrumentation aims to be as comprehensive and representative of the user experience as possible, and adheres to guidelines by the platform vendors. For this reason, App Starts reported by Sentry might be longer than what you see in other tools. Read more on the [Apple App Start docs](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#app-start-tracing) and [Android App Start docs](/platforms/android/tracing/instrumentation/automatic-instrumentation/#app-start-instrumentation).
+
+
+
+
+In the example below, the detail view of a trace displays the warm start measurement in the right sidebar.
+
+
+
+While the SDKs differentiate between cold and warm starts, they don't track hot starts or resumes. To get more insight into your cold and warm start metrics, you can use the [App Starts](/product/dashboards/sentry-dashboards/mobile/mobile-vitals/app-starts/) feature.
+
+## Performance Score
+
+Sentry categorizes average app start durations as follows:
+
+| Metric | Good | Meh | Poor |
+| --- | --- | --- | --- |
+| Average Cold App Start | less than 3s | between 3s and 5s | greater than 5s |
+| Average Warm App Start | less than 1s | between 1s and 2s | greater than 2s |
+
+## Slow and Frozen Frames
+
+To track the responsiveness of the user interface, Sentry measures _slow frames_ and _frozen frames_. Both indicate if the rendering of a frame is taking too long, causing the UI to appear laggy or frozen.
+
+Typically, a phone or tablet renders at 60 or 120 frames per second (fps). Based on this a single frame has a time budget of 16.67 / 8.33 ms to render.
+
+- **Slow Frames**: Using 60 fps, slow frames are frames that take more than 16 ms (Android) or 16.67 ms (iOS) to render.
+- **Frozen Frames**: Frozen frames are frames that take longer than 700 ms to render.
+
+Sentry also supports higher frame rates, especially as 120 fps displays are becoming more popular. For these apps, Sentry detects the frame rate and adjusts the slow frame calculation accordingly.
+
+On the Mobile Vitals dashboard you can see a slow and frozen frame rate, indicating the percentage of frames that are slow or frozen during the lifetime of the trace.
+
+In the example below, the detail view of the trace displays the slow, frozen, and total frames in an iOS application:
+
+
+
+You can track slow and frozen frames for:
+
+- [Android](/platforms/android/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
+- [Apple](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
+- [Flutter](/platforms/dart/guides/flutter/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
+- [React Native](/platforms/react-native/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
+
+## Frames Delay
+
+Frames Delay is the user-perceived total delayed duration of rendered frames. For example, at a refresh rate of 60fps, if a two frame renders takes 20ms each, the frame delay is 8ms (2 * (20ms - 16ms) = 8ms).
+
+You can track frames delay on the following platforms:
+- [Android](/platforms/android/tracing/instrumentation/perf-v2/#frames-delay)
+- [Apple, as part of slow and frozen frames](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
+- [Flutter](/platforms/dart/guides/flutter/integrations/slow-and-frozen-frames-instrumentation/)
+
+## Time to Initial Display and Time to Full Display
+
+To track how long it takes a screen to render its first frame and then how long it takes to render its first frame with all content, Sentry measures time to initial display and time to full display, respectively.
+
+- **Time to initial display**: tracks how long it takes your app to render its first frame. This includes app start time on the first screen loaded. It doesn't include any content loaded lazily after the first frame is drawn. Time to initial display is measured automatically and enabled by default.
+
+- **Time to full display**: tracks how long it takes for your mobile application to render its first frame with full content. This includes content loaded asynchronously after the first frame, for example, after loading content from the network. Time to full display is opt-in and requires you to manually call the API to report that the screen has loaded all of its content and is fully displayed.
+
+In the example below, the detail view of the trace displays the time-to-initial-display span in an Android application:
+
+
+
+You can track time to initial display for:
+
+- [Android](/platforms/android/tracing/instrumentation/automatic-instrumentation/#time-to-initial-display)
+- [Apple UIViewController](/platforms/apple/tracing/instrumentation/automatic-instrumentation/#time-to-initial-display)
+- [Apple SwiftUI](/platforms/apple/tracing/instrumentation/swiftui-instrumentation/#time-to-initial-display-and-time-to-full-display) (since 8.44.0)
+- [Flutter](/platforms/dart/guides/flutter/integrations/routing-instrumentation/#time-to-initial-display)
+- [React Native](/platforms/react-native/performance/instrumentation/time-to-display/#automatic-time-to-initial-display-for-react-navigation)
+
+You can track time to full display for:
+
+- [Android](/platforms/android/tracing/instrumentation/automatic-instrumentation/#time-to-full-display)
+- [Apple UIViewController](/platforms/apple/tracing/instrumentation/automatic-instrumentation/#time-to-full-display)
+- [Apple SwiftUI](/platforms/apple/tracing/instrumentation/swiftui-instrumentation/#time-to-initial-display-and-time-to-full-display) (since 8.44.0)
+- [Flutter](/platforms/dart/guides/flutter/integrations/routing-instrumentation/#time-to-full-display)
+- [React Native](/platforms/react-native/performance/instrumentation/time-to-display/#time-to-full-display)
+
+To get more insight into the performance of your time to initial display and time to full display metrics, use the [Screen Loads](/product/dashboards/sentry-dashboards/mobile/mobile-vitals/screen-loads/) feature.
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/screen-loads.mdx b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/screen-loads.mdx
new file mode 100644
index 0000000000000..4d12bad4ce19a
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/mobile/mobile-vitals/screen-loads.mdx
@@ -0,0 +1,83 @@
+---
+title: Screen Loads
+sidebar_order: 30
+description: >-
+ Learn how to monitor your mobile application's performance by using Screen
+ Loads to get better visibility on your application's TTID and TTFD
+ performance.
+og_image: /og-images/product-insights-mobile-mobile-vitals-screen-loads.png
+---
+
+
+
+The **Screen Loads** dashboard in [Sentry Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/) shows an overview of the amount of time it takes for your application to load its screens. It helps you identify slow or regressed screens and gives additional information so you can better understand the factors contributing to the slowness of both time to initial display (TTID) and time to full display (TTFD).
+
+Sentry tracks TTID automatically, but [TTFD](/product/dashboards/sentry-dashboards/mobile/mobile-vitals/#time-to-initial-display-and-time-to-full-display) requires that the `reportFullyDisplayed()` API be manually called to report that the screen has loaded all of its content and is fully displayed.
+
+### Minimum SDK Requirements:
+
+**For Android:**
+
+- `>=5.0` for automatic activity transactions
+- `>=6.10.0` for [TTID](/platforms/android/tracing/instrumentation/automatic-instrumentation/#time-to-initial-display)
+- `>=6.17.0` for [TTFD](/platforms/android/tracing/instrumentation/automatic-instrumentation/#time-to-full-display)
+
+**For iOS:**
+
+- `>=7.12.0` for UIViewController transactions
+- `>=8.4.0` for [TTID](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#time-to-initial-display)+[TTFD](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#time-to-full-display) for UIViewController
+- `>=8.44.0` for [TTID+TTFD for SwiftUI](/platforms/apple/tracing/instrumentation/swiftui-instrumentation/#time-to-initial-display-and-time-to-full-display)
+
+**For Flutter:**
+
+- `>=7.18.0` [TTID+TTFD for Routing Instrumentation](/platforms/dart/guides/flutter/integrations/routing-instrumentation/#time-to-initial-display)
+
+**For React Native:**
+
+- `>=5.20.0` [TTID+TTFD for React Navigation](/platforms/react-native/performance/instrumentation/time-to-display/)
+
+By default, the **Screen Loads** dashboard displays metrics related to all releases. To choose a different set of releases to compare, use the **Releases** filter at the top of the dashboard.
+
+The charts section shows a comparison of TTID and TTFD metrics for your selected releases over time.
+
+**Reasons Why You Might Not Be Seeing Any Data:**
+
+- You don't have any transactions with op `ui.load`
+- Your SDKs don't meet the minimum SDK requirements
+
+
+Here, you'll see a breakdown of TTID and TTFD values by [device class](/concepts/search/searchable-properties/#device-classification) (high, medium, low, or unknown), across your selected releases. This will help you understand how users with different device performance levels are being affected.
+
+To see slow TTID and TTFD events and profiles for each release broken out by specific device class, use the "Device Class" filter below the charts.
+
+At the bottom of the dashboard, you'll see a table of spans that occurred during screen load, sorted by the most time your screen spent in that span. Here, you'll be able to:
+
+- Spot span regressions by comparing the average duration of each span across your two releases of choice.
+
+- Find the slowest spans in the release you're interested in by looking at average span duration.
+
+- See which spans occur most frequently by looking at the contribution rates. (This might help you identify excessive io calls or repeated work that might be occurring during screen load.)
+
+**Eligible span operations:**
+
+- file.read
+- file.write
+- ui.load
+- http.client
+- db
+- db.sql.query
+- db.sql.transaction
+
+### TTID and TTFD affecting spans:
+
+If spans end before TTID or TTFD, there's a chance they could be affecting their respective metrics. They're tagged in Sentry and can be viewed on the **Screen Loads** dashboard. But just because a span has been identified as TTID or TTFD-affecting, it doesn't necessarily mean it's the culprit. This information is an approximation and should be used to find potentially problematic spans on an aggregate level so you can narrow down the scope of spans you need to investigate.
+
+
+
+## Span Detail View
+
+
+
+Clicking on a span description takes you to the Traces page, where you can see a list of related sampled spans.
+
+Once on a trace view, you can click over to **Profiles** to investigate [flamegraphs](/product/explore/profiling/flame-charts-graphs/) for the span to see where the most time is being spent.
\ No newline at end of file
diff --git a/docs/product/dashboards/sentry-dashboards/mobile/session-health.mdx b/docs/product/dashboards/sentry-dashboards/mobile/session-health.mdx
new file mode 100644
index 0000000000000..41645c0ae08b6
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/mobile/session-health.mdx
@@ -0,0 +1,35 @@
+---
+title: Session Health
+sidebar_order: 40
+description: "Get insights about your application's session health over time."
+---
+
+
+
+
+## Charts
+
+For the Mobile dashboard, found on [Sentry Dashboards](https://sentry.io/orgredirect/organizations/:orgslug/dashboards/), you can see widgets like:
+
+- [Crash Free Sessions](/product/releases/health/#crash-free-sessionsusers)
+- [Total Sessions by Release](/product/releases/health/#session)
+- Releases
+- Session Health
+- User Health (Crash Free Users)
+
+The Crash Free Sessions chart extracts out a single status — "crashed" — to highlight the crash free rate of the 5 most adopted releases in the selected projects. In this case, we define "adoption" as the percent of sessions occurring in that release, out of the total number of sessions in the selected projects. This metric is a key measurement to assess the health of your application.
+
+The Total Sessions by Release shows how many sessions occur in each of the 5 most recent releases. The most recent 5 releases are shown.
+
+Looking at the Issues Count widget, you can hover over a count of releases at the bottom of the chart, and click to see a list of releases and any issues associated with them.
+
+You can customize this dashboard by updating filters or duplicating it to create a new dashboard.
+
+## Releases Table
+
+At the bottom of Mobile Session Health dashboard is a table listing releases for selected projects.
+
+The table contains key information about each release, including:
+
+- [Crash free rate](/product/releases/health/#crash-free-sessionsusers)
+- [Total session count](/product/releases/health/#sessions)
diff --git a/docs/product/dashboards/sentry-dashboards/outbound-api-requests.mdx b/docs/product/dashboards/sentry-dashboards/outbound-api-requests.mdx
new file mode 100644
index 0000000000000..215a8c21a805f
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/outbound-api-requests.mdx
@@ -0,0 +1,68 @@
+---
+title: Outbound API Requests
+sidebar_order: 15
+description: "Track the performance of your application's HTTP requests and drill into the domains serving those requests."
+---
+
+This page applies to outbound HTTP requests from **frontend**, **mobile**, and **backend** applications. With performance monitoring enabled, Sentry tracks all outgoing HTTP requests and helps you investigate the domains that serve those requests.
+
+On the [Requests page](#requests-page), you get an overview of the domains that serve your application's outgoing requests. From there, you can check each individual domain's behavior on its [Domain Summary page](#domain-summary-page) and find sample events in the [Sample List](#sample-list).
+
+## Prerequisites and Limitations
+
+
+Network requests using non-HTTP protocols (FTP, WebSocket, etc.) are not supported at this time.
+
+
+Availability of HTTP request monitoring depends on the SDK your application uses. In most cases, Sentry's SDKs automatically enable HTTP request tracking. You can check your SDK's automatic instrumentation documentation to see if it includes tracking HTTP requests.
+
+If the SDK you're using doesn't automatically instrument HTTP requests, you can set up custom instrumentation. Dedicated platform documentation is available for these platforms:
+
+- [Python SDK](/platforms/python/tracing/instrumentation/custom-instrumentation/requests-module/)
+- [JavaScript SDK](/platforms/javascript/guides/node/tracing/instrumentation/custom-instrumentation/requests-module/)
+
+If your platform doesn't have dedicated custom instrumentation instructions, you can try adapting the code from one of the supported platforms. In addition, you can also reference the [Requests Modules SDK development guide](https://develop.sentry.dev/sdk/performance/modules/requests/), which lists required span properties and their expected format.
+
+## Requests Page
+
+The **Requests** page gives an overview of the domains that your application accesses via HTTP. You can use this page to see how those domains perform, including their average response duration and the rate of 3xx, 4xx, and 5xx HTTP response status codes.
+
+You can access the **Requests** page by clicking "Requests" in the sidebar, under "Sentry Dashboards". The **Performance** page also shows the most time-consuming outgoing HTTP request domains in the "Most Time-Consuming Domains" widget. From there, you can click "View All" to open the **Requests** page.
+
+At the top of the page, there are three graphs that summarize the overall behavior of outgoing HTTP requests: a requests per minute (throughput) chart, an average duration chart, and a chart that shows the percentage of 3xx, 4xx, and 5xx HTTP response status codes. You can click and drag to select a specific time range directly in a graph.
+
+The domains table below the charts shows a list of domains your application makes requests to. The domain names are parameterized, where `*` means that all subdomains of that domain are included. Each row also shows the project that issued the requests, throughput, average duration, HTTP response code rate, and total time your app spent making requests to the domain (time spent).
+
+By default, the table is sorted by most time spent, which serves as a proxy for the relative performance impact of a given domain. You can also sort by throughput, duration, and HTTP response status code rate by clicking on the relevant column header. The domain search bar also lets you search for specific domains.
+
+To view more details, click on a domain name to open its **Domain Summary** page.
+
+
+If Sentry cannot extract the domain of the outgoing HTTP request, it will group the requests in a special table row named "Unknown Domain". This can happen because of malformed URLs, or old JavaScript SDKs that don't support relative URLs. To fix this problem in JavaScript projects, please upgrade to version [7.111.0](https://github.com/getsentry/sentry-javascript/releases/tag/7.111.0) or above.
+
+
+## Domain Summary Page
+
+To open a domain's **Domain Summary** page, click on the domain from the table on the **Requests** page, or click on the individual rows in the "Most Time-Consuming Domains" widget on the **Performance** page.
+
+At the top of the page, you'll see the same throughput, duration, and response status code charts. You'll also see a link to the domain's status page, if one is known.
+
+Below, you'll find a list of transactions that make requests to that domain, sorted by time spent.
+
+If you want to investigate a specific transaction, click on it to open the request samples panel.
+
+## Sample List
+
+Click on a transaction to open its sample list. The sample list side panel shows metrics on this domain's behavior within the selected transaction. You can choose to view a breakdown either by duration or by response code.
+
+### Duration Breakdown
+
+The duration breakdown shows the average duration of requests to the domain in the selected transaction. It also finds relevant samples to help you investigate the requests. Sentry tries to find samples that are faster than, slower than, and roughly equal to the average duration. The samples will also span the entire selected time range, if possible. Each sample is plotted on the duration chart and represented as a triangle.
+
+The samples are also listed in a table below the chart. Each sample has a link to the relevant trace, the HTTP status of the response, and the full URL of the request.
+
+### Response Code Breakdown
+
+The response code breakdown chart plots the top 5 most common response status codes over time. You can use this chart to diagnose response code behavior. You can use the response code range selector in the top right to narrow down the status codes. For example, if you select the "3XX" value, the breakdown chart will narrow down to only 3XX HTTP status codes. You can click on the status code badges in the top right of the breakdown chart to show and hide the corresponding status code chart line.
+
+The table below the chart shows a list of sample spans for the selected response code range. Each sample has a link to the relevant trace, the HTTP status of the response, and the full URL of the request.
diff --git a/docs/product/dashboards/sentry-dashboards/transaction-summary.mdx b/docs/product/dashboards/sentry-dashboards/transaction-summary.mdx
new file mode 100644
index 0000000000000..a78cded9f77de
--- /dev/null
+++ b/docs/product/dashboards/sentry-dashboards/transaction-summary.mdx
@@ -0,0 +1,172 @@
+---
+title: Transaction Summary
+sidebar_order: 40
+description: >-
+ Learn more about the transaction summary, which helps you evaluate the
+ transaction's overall health. This view includes graphs, instances of these
+ events, stats, facet maps, and related errors.
+og_image: /og-images/product-insights-overview-transaction-summary.png
+---
+
+Every transaction has a summary view that gives you a better understanding of its overall health. With this view, you'll find graphs, instances of these events, stats, facet maps, related errors, and more.
+
+
+
+## What Is a Transaction?
+
+A transaction represents a single instance of an activity you want to measure or track, like a page load, page navigation, or an asynchronous task. Having transaction information lets you monitor the overall performance of your application beyond when it crashes or generates an error. Without transactions, you can only know when things in your application have actually gone wrong, which is important, but not the whole picture.
+
+Transactions on the **Sentry Dashboards** view are grouped by the transaction names, such as endpoint paths for backend request transactions (like `/store/checkout/` or `api/v2/users//`) or URLs/routes for page load transactions (like `https://docs.sentry.io/product/dashboards/sentry-dashboards/`). When you click a transaction on the **Sentry Dashboards** view, it takes you to the **Transaction Summary**, where you can see a list of transaction events: that is, the individual instances of that specific transaction.
+
+
+
+Learn more about setting transaction names in our [SDK documentation](/platform-redirect/?next=/enriching-events/transaction-name/).
+
+
+
+Learn about how to control the type and amount of transactions you send to Sentry, in [Manage Your Transaction Quota](/pricing/quotas/manage-transaction-quota/). For a more in-depth explanation of what's in a transaction as it relates to traces, check out our [full tracing documentation](/product/sentry-basics/tracing/).
+
+## Overview
+
+### Filter and Search
+
+While you can use the search field to narrow down your events, you can also filter by http, db, browser, and resource by toggling between operations in the "Filter" menu. This filtering is reflected in the rest of the page, which provides you with more targeted drill-downs.
+
+### Graphs
+
+- **Duration Breakdown:** By graphing [P50](#p50-threshold), [P75](#p75-threshold), [P95](#p95-threshold), [P99](#p99-threshold), and P100 durations distinctly, you can utilize this display to see their transaction performance over time. Toggle the display of each segment by clicking on the legend (including Releases). Also, zoom in on specific slices to investigate spikes or possible performance regressions from a release.
+
+- **Duration Percentiles:** This graph shows the [average transaction duration](#average-transaction-duration) across distinct percentiles. For example, see how different the P50 and P99 response time durations are for a given transaction and understand the rate of increase between segments.
+
+- **Duration Distribution:** This graph shows the volume of transactions per median duration. This view helps you understand the spread of the transaction durations in order to determine the likelihood of different outcomes. For example, what transaction duration is the most likely for a user.
+
+- **Trends:** This graph uses a modified version of [ASAP](https://arxiv.org/pdf/1703.00983.pdf) smoothing. The Trends graph shows the unsmoothed data of the Display data, along with a smoothed version of that data.
+
+- **Web Vitals:** This graph displays the [P75 threshold](#p75-threshold) of [First Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#first-paint-fp), [First Contentful Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#first-contentful-paint-fcp), [Largest Contentful Paint](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#largest-contentful-paint-lcp), and [First Input Delay](/product/dashboards/sentry-dashboards/frontend/web-vitals/web-vitals-concepts/#first-input-delay-fid) over time. This view helps you understand how the Web Vitals associated with the transaction are performing over time.
+
+- **User Misery:** This graph displays the [User Misery](#user-misery) score for the transaction. User Misery is a score that represents the number of unique users who have experienced load times four times the project's configured threshold.
+
+### Transaction Table
+
+On initial load, the table displays slow occurrences of the transaction along with the Event ID, User, Operations Duration, Total Transaction Duration, and Timestamp of the event. Click on the Event ID or the Trace ID to open the [Trace View](/concepts/key-terms/tracing/trace-view/#product-walkthrough-trace-details-page) page. Other sets of transactions you can browse through are below.
+
+- Fastest Transactions
+- Slow Transactions (p95)
+- Outlier Transactions (p100)
+- Recent Transactions
+
+The table also updates dynamically if you change any of the project, environment, or date range filters or when you drill in on a latency segment (applicable when viewing the Latency Histogram).
+
+When viewing transactions, you may want to create more curated views. Click "Open in Discover" above the table to create a custom query to investigate further. For more details, see the full documentation for the Discover [Query Builder](/product/explore/discover-queries/query-builder/).
+
+
+
+Currently, only transaction data — the transaction name and any attributes the transaction inherits from its root span — is searchable. Data contained in spans other than the root span is not indexed and therefore cannot be searched.
+
+
+
+### Suspect Spans
+
+The transaction summary includes a list of suspect spans that correspond to where most of the time in a transaction is spent. By default, we sort spans by the total self time. When you click the "Example Transaction" event, it takes you directly to the span in question.
+
+### Suspect Tags
+
+The transaction summary includes a list of suspect tags that often correspond to slower transactions. By default, we sort tags by the total time lost. The list includes additional information:
+
+- **Tag Key**: The tag category (for example, device, geo)
+- **Tag Value**: The specific tag value (for example, Android, South America)
+- **Avg (Tag) Duration**: Provides the average duration for a transaction with this tag
+- **Comparison to Avg**: Indicates how much slower or faster this tag is than the average duration of this transaction
+- **Total Time Lost**: Calculates how much total time you've lost in the selected time range when comparing the average tag duration to the average transaction duration
+
+To investigate why these tags are affecting performance, click on the tag value to filter the transaction summary further.
+
+### Related Issues
+
+This table will show you all related issues. In other words, any errors that are associated with this transaction. Click "Open in Issues" to see the full list.
+
+### Sidebar
+
+The sidebar contains helpful supplementary information about this transaction's [User Misery](#user-misery), [Apdex](#apdex), [Throughput](#throughput-total-tpm-tps), [Latency](#latency), and more. You'll also find a Tag Summary (facet map) for a list of common tags related to this transaction.
+
+## Metrics in This View
+
+
+
+## Tags
+
+The **Tags** tab displays a list of suspect tag keys that often correspond to slower transactions. Toggle through them to have the corresponding tag values reflected in the heat map. Similar to a histogram, events are distributed by duration. Click on any purple box to view a list of events or continue to filter down the events by adding values to the filter in the table below the heat map. Use the "X-Axis" dropdown to aggregate the events by transaction duration or by Largest Contentful Paint (LCP).
+
+
+
+## All Events
+
+The table in **All Events** tab offers a full list of transactions broken down similar to the abbreviated table in the overview. Filters are carried across from other views. You can also narrow the events down by percentile.
+
+## Spans
+
+The "Spans" tab displays a list of suspect spans that correspond to where most of the time in a transaction is being spent, and it can help you find spans where performance problems lie.
+
+Choose from one of several [metrics](#metrics) to sort spans and identify different types of problems. Filter spans to only see the span operation type you're interested in.
+
+### Span Summary
+
+Clicking on a span will take you to its summary page which will give you more details about this specific span [group](#grouping). On the page, you can see the performance of the span over time and see a list of transaction events that contain the span.
+
+
+
+This span distribution feature is available only if you're in the Early Adopter program. Features available to Early Adopters are still in-progress and may have bugs. We recognize the irony. If you're interested in being an Early Adopter, you can turn your organization's Early Adopter status on/off in General Settings. This will affect all users in your organization and can be turned back off just as easily.
+
+
+
+If you're in the Early Adopter program, you can also see the distribution of the span self time using the (added) "Display" dropdown. This histogram can help you identify systemic performance issues across the entire dataset by showing how self time for every span instance is distributed.
+
+You can also select a subset of the dataset by zooming into the distribution histogram. The stats and transaction events table will reflect that change and will only include spans with self time that are within the bounds of your subset. This allows you to focus on the best or worse performing spans so you can troubleshoot performance issues more easily.
+
+### Self Time
+
+Suspect spans are determined using a span's self time rather than its duration. To calculate a span's self time, take the interval of the span and subtract the intervals of any child spans. The duration of the remaining interval is the span's self time.
+
+In the example below, the self time of each span is highlighted by the darker areas. For example, the `http.server` has a self time of 10ms + 15ms = 25ms.
+
+
+
+### Metrics
+
+- **Total Self Time**: The sum of the [self time](#self-time) for a span. This metric is useful to identify the span where the majority of the time is being spent.
+- **Average Count**: The average number of times a span appears in a transaction. This metric is useful to identify redundant work being done within a transaction. It is often indicative of an n + 1 problem.
+- **Total Count**: The total number of times a span appears across all transactions. This metric is useful to identify spans that appear most frequently.
+- **p50 Self Time**: The 50th percentile of the [self time](#self-time) for a span. This metric is useful to identify spans that take a long time individually.
+- **p75 Self Time**: The 75th percentile of the [self time](#self-time) for a span. This metric is useful to identify spans that take a long time individually.
+- **p95 Self Time**: The 95th percentile of the [self time](#self-time) for a span. This metric is useful to identify spans that take a long time individually.
+- **p99 Self Time**: The 99th percentile of the [self time](#self-time) for a span. This metric is useful to identify spans that take a long time individually.
+
+### Grouping
+
+Spans with the same operation and description are grouped together into a single span group. Some processing is done to group similar spans together. If you find that the span grouping is not ideal, you can change this by making sure the spans you want grouped together have the same operation and description.
+
+### Replays
+
+The Replays tab displays a list of replays where the transaction you're viewing had occurred. Go directly to [Replay Details](/product/explore/session-replay/web/replay-details/) for any replay and see how a slow transaction impacted the user experience. Note: you must have [Session Replay](/product/explore/session-replay/) enabled to see this tab.
+
+## Additional Actions
+
+### Starring Important Transactions
+
+If you find an important transaction you want to return to, click "Star for Team" in the upper right corner to mark it as a key transaction for any of your teams. This will be saved so you can view this from your [Sentry Dashboards](/product/dashboards/sentry-dashboards/) homepage. The transactions you star will be shared with members of the same team and each team can have up to 100 starred transactions.
+
+### Creating Alerts
+
+To create a metric alert rule for this transaction, click [Create Alert](/product/alerts-notifications/metric-alerts/) at the top of the page.
+
+## Extracted Metrics in Dashboard Widgets [Deprecated]
+
+
+This feature is a deprecated feature only available to legacy customers.
+
+
+If you are building a widget with transaction data, and would like to use event-like filters (eg. `transaction.duration:>100ms`) or custom tags that you set on your transactions, we will routinely collect metrics to show you accurate counts and rates.
+
+Not all widgets are compatible with metrics extraction. The following cases will cause your widget to continue using event-backed data:
+- Equations — Using equations will show you event data instead of metrics.
+- Widgets that display data from errors and transactions simultaneously — Extraction only happens for transaction data. You need to use the `event.type:transaction` filter along with your custom tags in order to get extracted metrics.
\ No newline at end of file
diff --git a/docs/product/dashboards/widget-builder/img/editing-widget-filter.png b/docs/product/dashboards/widget-builder/img/editing-widget-filter.png
new file mode 100644
index 0000000000000..ad96e370bbfd8
Binary files /dev/null and b/docs/product/dashboards/widget-builder/img/editing-widget-filter.png differ
diff --git a/docs/product/dashboards/widget-builder/img/widget-builder-filter-your-results-example.png b/docs/product/dashboards/widget-builder/img/widget-builder-filter-your-results-example.png
deleted file mode 100644
index a3c27f2b7d9a1..0000000000000
Binary files a/docs/product/dashboards/widget-builder/img/widget-builder-filter-your-results-example.png and /dev/null differ
diff --git a/docs/product/dashboards/widget-builder/img/widget-builder-hero.png b/docs/product/dashboards/widget-builder/img/widget-builder-hero.png
new file mode 100644
index 0000000000000..139dcec33faa4
Binary files /dev/null and b/docs/product/dashboards/widget-builder/img/widget-builder-hero.png differ
diff --git a/docs/product/dashboards/widget-builder/img/widget-builder-overview.png b/docs/product/dashboards/widget-builder/img/widget-builder-overview.png
deleted file mode 100644
index f7d837c5a1740..0000000000000
Binary files a/docs/product/dashboards/widget-builder/img/widget-builder-overview.png and /dev/null differ
diff --git a/docs/product/dashboards/widget-builder/img/widget-builder-thresholds-hover.png b/docs/product/dashboards/widget-builder/img/widget-builder-thresholds-hover.png
deleted file mode 100644
index cbff7212de3d2..0000000000000
Binary files a/docs/product/dashboards/widget-builder/img/widget-builder-thresholds-hover.png and /dev/null differ
diff --git a/docs/product/dashboards/widget-builder/img/widget-builder-thresholds.png b/docs/product/dashboards/widget-builder/img/widget-builder-thresholds.png
deleted file mode 100644
index 113c883f3fc52..0000000000000
Binary files a/docs/product/dashboards/widget-builder/img/widget-builder-thresholds.png and /dev/null differ
diff --git a/docs/product/dashboards/widget-builder/index.mdx b/docs/product/dashboards/widget-builder/index.mdx
index 4d8cb4397f71b..41c903fc7cb37 100644
--- a/docs/product/dashboards/widget-builder/index.mdx
+++ b/docs/product/dashboards/widget-builder/index.mdx
@@ -5,9 +5,9 @@ description: Learn how to create widgets for your dashboards or edit existing on
og_image: /og-images/product-dashboards-widget-builder.png
---
-When adding a widget or editing an existing one, a side panel opens up where you can see the dashboard widget builder:
+When adding a widget or editing an existing one, a side panel opens up where you can see the dashboard widget builder.
-
+
The widget builder has several configuration options that you can use to shape data and add information to your dashboard. These options are presented as steps in the widget builder, but you don't have to do them in the order they're presented in.
@@ -130,7 +130,7 @@ Use this field to filter your results by the searchable properties of your [data
On [time-series visualizations](/product/dashboards/widget-builder/#area-chart--bar-time-series--line-chart) you can add up to three queries to filter your results, each with their own search conditions, to compare results. Each query will generate a new series in your chart for each y-axis. To make it easier to differentiate between them in the legend and tooltip, you can add a legend alias that will be added as a prefix to the labels, as in the example below:
-
+
## Group by
@@ -138,7 +138,7 @@ The option to group results is only available for [time-series visualizations](/
If two or more groups are added, a draggable element will be displayed that you can use to sort the fields, but the sort does not impact how your data is displayed in the visualization:
-
+
## Sort by
@@ -148,7 +148,7 @@ The option to sort in timeseries charts is only available if you've applied a gr
If you select “Custom Equation”, an extra field appears where you can enter an equation of your choice that will be applied to the query:
-
+
## Limit
@@ -156,24 +156,8 @@ The option to limit your results is only available for [time-series visualizatio
## Set Thresholds
-The option for setting thresholds is only available for [big number visualizations](/product/dashboards/widget-builder/#big-number). Thresholds help identify problematic widgets with colored indicators. Hovering over the colored indicators at the dashboard level displays the thresholds associated with a widget. Units can be attached to thresholds for duration or rate metric types. An example metric with units would be “p95 of all transactions”.
-
-
-
-
+Thresholds help identify problematic widgets with colored indicators. They can be set for area, line, or big number visualizations. For [big number visualizations](/product/dashboards/widget-builder/#big-number), you can see the set threshold values when you hover over the color indicator on the widget. For the rest, the current threshold range will be displayed as the color of the widget's background.
## Widget Title
By default, all new widgets are titled “Custom Widget”, but you can edit the title by clicking on the text. We recommend you update the title.
-
-## Extracted metrics
-
-
-
-If you are building a widget with transaction data, and would like to use event-like filters (eg. `transaction.duration:>100ms`) or custom tags that you set on your transactions, we will routinely collect metrics to show you accurate counts and rates.
-
-
-
-Not all widgets are compatible with metrics extraction. The following cases will cause your widget to continue using event-backed data:
-- Equations — Using equations will show you event data instead of metrics.
-- Widgets that display data from errors and transactions simultaneously — Extraction only happens for transaction data. You need to use the `event.type:transaction` filter along with your custom tags in order to get extracted metrics.
diff --git a/docs/product/dashboards/widget-library/img/response-threshold-widget.png b/docs/product/dashboards/widget-library/img/response-threshold-widget.png
new file mode 100644
index 0000000000000..894b4d056ab72
Binary files /dev/null and b/docs/product/dashboards/widget-library/img/response-threshold-widget.png differ
diff --git a/docs/product/dashboards/widget-library/img/widget-library-response-thresholds-widget.png b/docs/product/dashboards/widget-library/img/widget-library-response-thresholds-widget.png
deleted file mode 100644
index 3a79b58934616..0000000000000
Binary files a/docs/product/dashboards/widget-library/img/widget-library-response-thresholds-widget.png and /dev/null differ
diff --git a/docs/product/dashboards/widget-library/index.mdx b/docs/product/dashboards/widget-library/index.mdx
index 51a5cf5631e03..f33f43f4fdd08 100644
--- a/docs/product/dashboards/widget-library/index.mdx
+++ b/docs/product/dashboards/widget-library/index.mdx
@@ -11,16 +11,21 @@ The widget library contains a collection of prebuilt widgets you can add to your
The library includes the following widgets:
-- **Duration Distribution**: A multiple data series chart visualizing the distribution of transaction duration across various percentiles (p50, p75, and p95)
-- **High Throughput Transactions**: The top five transactions with the largest number of events, represented in an area chart
-- **LCP by Country**: Table showing the p75 of page load times for each country
-- **Miserable Users**: The total number of unique users who have experienced slow transactions (transaction duration greater than 1200ms)
-- **Slow vs. Fast Transactions**: Bar chart comparing the percentage of transactions that are over 300ms (slow) and under 300ms (fast)
-- **Issues For Review**: A table of unresolved issues for review, ordered by the most recently seen issues
-- **Top Unhandled Error Types**: The most frequently encountered unhandled errors
-- **Users Affected by Errors**: A comparison of the total number of errors and the number of unique users affected by the errors
-- **Crash Rates for Recent Releases**: Percentage of crashed sessions for your recent releases
-- **Session Health**: The total number of abnormal, crashed, errored, and healthy sessions
+- **Duration Distribution**: Compare transaction durations across different percentiles.
+- **High Throughput Transactions**: Top 5 transactions with the largest volume.
+- **Crash Rates for Recent Releases**: Percentage of crashed sessions for latest releases.
+- **Session Health**: Number of abnormal, crashed, errored, and healthy sessions.
+- **LCP by Country**: Table showing page load times by country.
+- **Slow vs. Fast Transactions**: Count breakdown of transaction durations over and under 300ms.
+- **Performance Score**: Tracks the overall performance rating of the pages in your selected project.
+- **SSR File Tree**: Visualizes the file tree of the server-rendered components in your Next.js project.
+- **Rage and Dead Clicks**: Visualizes the rage and dead clicks in your frontend project.
+- **Issues For Review**: Most recently seen unresolved issues for review.
+- **Top Unhandled Error Types**: Most frequently encountered unhandled errors.
+- **Users Affected by Errors**: Footprint of unique users affected by errors.
+- **Error Count By Transaction**: Compare error volume across your top transactions.
+
+
You can change the title, queries, fields, visualization types, sort order, and other fields of these prebuilt widgets to suit your use case by clicking the context menu on the widget and selecting "Edit Widget".
@@ -49,23 +54,23 @@ The "Duration Distribution" widget shows the spread of transaction duration time
Set one of the y-axis values to `count()` and remove the other two axes:
-- Y-Axis: `count()`
+- Y-Axis: `count() spans`
-To the first query, add the search condition for satisfactory transaction duration (this example uses 300ms as the satisfactory response threshold):
+To the first filter, add the search condition for satisfactory span duration (this example uses 300ms as the satisfactory response threshold):
-- Search condition 1: `transaction.duration:<300`
+- Search condition 1: `span.duration:<300`
-Add another query for the tolerable condition by clicking the "Add Query" button. In this example, we're using the [Apdex](/product/insights/overview/metrics/#apdex) definition where tolerable response times are between the satisfactory threshold and four times the satisfactory threshold:
+Add another filter by clicking the "Add Query" button. In this example, we're using the [Apdex](/product/dashboards/sentry-dashboards/transaction-summary/#apdex) definition where tolerable response times are between the satisfactory threshold and four times the satisfactory threshold:
-- Search condition 2: `transaction.duration:<1200 AND transaction.duration:>=300`
+- Search condition 2: `span.duration:<1200 AND span.duration:>=300`
-Finally, add a third query for for the frustrating transaction duration:
+Finally, add a third filter for the duration:
-- Search condition 3: `transaction.duration:>=1200`
+- Search condition 3: `span.duration:>=1200`
The chart now shows cumulative counts at different response time thresholds.
-
+
### My top issues
diff --git a/docs/product/explore/discover-queries/query-builder.mdx b/docs/product/explore/discover-queries/query-builder.mdx
index 2fe00f804dc43..88586be87c13e 100644
--- a/docs/product/explore/discover-queries/query-builder.mdx
+++ b/docs/product/explore/discover-queries/query-builder.mdx
@@ -145,6 +145,8 @@ You can also add the following functions as columns to stack events, depending o
Each function will ask you to assign a parameter. Some are required while others are optional. Functions will stack events based on the same values. If no functions are applied, the events in your "Query Results" table will remain individually listed. Once you are done editing the columns, click "Apply" and results will be reflected in the query results. Keep in mind, the table may horizontally scroll if many columns are added.
+For definitions of Apdex, User Misery, failure rate, throughput, latency percentiles, and related metrics, see [Metrics in Transaction Summary](/product/dashboards/sentry-dashboards/transaction-summary/#metrics-in-this-view).
+
### Cell Filters
Each cell in the table will have an ellipsis appear on hover. This will open a context menu with additional filtering capabilities depending on the value type. For example, you can selectively target a transaction to the search conditions bar by clicking on "Add to filter".
diff --git a/docs/product/explore/discover-queries/query-builder/query-equations.mdx b/docs/product/explore/discover-queries/query-builder/query-equations.mdx
index 7aa10fc11bcf2..6cb63dc3e7b57 100644
--- a/docs/product/explore/discover-queries/query-builder/query-equations.mdx
+++ b/docs/product/explore/discover-queries/query-builder/query-equations.mdx
@@ -106,7 +106,7 @@ Get the percentage of transactions that completed within a threshold
### Calculate a custom Apdex
-[Apdex](/product/insights/overview/metrics/#apdex) is defined as `(satisfied + tolerable*0.5 + frustrated*0)/total`. If you wanted to change the weight of tolerable to 0.2, you would create the following query and equation.
+[Apdex](/product/dashboards/sentry-dashboards/transaction-summary/#apdex) is defined as `(satisfied + tolerable*0.5 + frustrated*0)/total`. If you wanted to change the weight of tolerable to 0.2, you would create the following query and equation.
1. Create a new query with the following four columns:
- Column 1:
diff --git a/docs/product/insights/backend/queries.mdx b/docs/product/insights/backend/queries.mdx
index e53ab0502693a..a3914fd4f40bd 100644
--- a/docs/product/insights/backend/queries.mdx
+++ b/docs/product/insights/backend/queries.mdx
@@ -45,7 +45,7 @@ If you are using
+This feature is a deprecated feature only available to legacy customers.
+
+
+If you are building a widget with transaction data, and would like to use event-like filters (eg. `transaction.duration:>100ms`) or custom tags that you set on your transactions, we will routinely collect metrics to show you accurate counts and rates.
+
+
+
+Not all widgets are compatible with metrics extraction. The following cases will cause your widget to continue using event-backed data:
+- Equations — Using equations will show you event data instead of metrics.
+- Widgets that display data from errors and transactions simultaneously — Extraction only happens for transaction data. You need to use the `event.type:transaction` filter along with your custom tags in order to get extracted metrics.
\ No newline at end of file
diff --git a/docs/product/projects/project-details/index.mdx b/docs/product/projects/project-details/index.mdx
index 07ee66d356483..6c8a682b7eb38 100644
--- a/docs/product/projects/project-details/index.mdx
+++ b/docs/product/projects/project-details/index.mdx
@@ -11,7 +11,7 @@ The top four cards display the following:
- Crash free [sessions](/product/releases/health/#session)
- Crash free users
- Number of [releases](/product/releases/)
-- [Apdex](/product/insights/overview/metrics/#apdex)
+- [Apdex](/product/dashboards/sentry-dashboards/transaction-summary/#apdex)
The two graphs below the cards show the value of a specific metric over the specified time range. Click on the graph legend to show or hide an overlay of the previous time period and any releases (if set up).
@@ -23,9 +23,9 @@ By default, the graphs show crash free sessions and Apdex, but you can toggle th
- Crash free [sessions](/product/releases/health/#session)
- Crash free users
-- [Apdex](/product/insights/overview/metrics/#apdex)
-- [Failure rate](/product/insights/overview/metrics/#failure-rate)
-- [Transactions per minute](/product/insights/overview/metrics/#throughput-total-tpm-tps)
+- [Apdex](/product/dashboards/sentry-dashboards/transaction-summary/#apdex)
+- [Failure rate](/product/dashboards/sentry-dashboards/transaction-summary/#failure-rate)
+- [Transactions per minute](/product/dashboards/sentry-dashboards/transaction-summary/#throughput-total-tpm-tps)
- Number of errors
- Number of sessions
- Number of transactions
diff --git a/docs/product/releases/release-details.mdx b/docs/product/releases/release-details.mdx
index f731097de44d7..74a1ccdda9074 100644
--- a/docs/product/releases/release-details.mdx
+++ b/docs/product/releases/release-details.mdx
@@ -18,7 +18,7 @@ The graph at the top of the page provides insights into the health of your relea
- [Crash Free User Rate](/product/releases/health/#crash-free-sessionsusers)
- Crashed Session Rate
- [Crashed User Rate](/product/releases/health/#crashed-users)
-- [Failure Rate](/product/insights/overview/metrics/#failure-rate)
+- [Failure Rate](/product/dashboards/sentry-dashboards/transaction-summary/#failure-rate)
- [Session Count](/product/releases/health/#session)
- Error Count
- Transaction Count
diff --git a/includes/custom-measurements-blurb.mdx b/includes/custom-measurements-blurb.mdx
new file mode 100644
index 0000000000000..46c7cd55b5a1f
--- /dev/null
+++ b/includes/custom-measurements-blurb.mdx
@@ -0,0 +1,3 @@
+Sentry supports **custom performance measurements** on transactions: you define measurements that matter to your application (for example, memory usage, query time, or user action counts) and send them with the transaction from your SDK. They appear in **Dashboards**, **Discover**, and transaction trace detail. You can define up to 10 custom measurements per transaction; any additional ones are truncated. Configure and send them in your SDK; supported platforms:
+
+
diff --git a/includes/dashboards-session-health-body.mdx b/includes/dashboards-session-health-body.mdx
new file mode 100644
index 0000000000000..ff7c5913a74fa
--- /dev/null
+++ b/includes/dashboards-session-health-body.mdx
@@ -0,0 +1,7 @@
+If you have [sessions and releases](/product/releases/setup/) enabled on Sentry, you can take advantage of the Session Health dashboard. The Session Health dashboard contains a variety of data visualizations to help you discover insights about how your sessions are performing. A session on most web or mobile applications is created for every page (or view) load and on every navigation change. Read more [here](/product/releases/health/#sessions).
+
+The charts help you understand trends for your sessions over time, and the customized chart views and toggleable legends allow you to drill down into the metrics you care about most.
+
+## Prerequisites
+
+You must have [sessions and releases](/product/releases/setup/) enabled in order to view these insights. Session Health is available only for the Frontend and Mobile modules.
diff --git a/includes/insights-requests-body.mdx b/includes/insights-requests-body.mdx
index c40388a615bc9..325dc5d1b9ee2 100644
--- a/includes/insights-requests-body.mdx
+++ b/includes/insights-requests-body.mdx
@@ -25,7 +25,7 @@ If your platform doesn't have dedicated custom instrumentation instructions, you
The **Requests** page gives an overview of the domains that your application accesses via HTTP. You can use this page to see how those domains perform, including their average response duration and the rate of 3xx, 4xx, and 5xx HTTP response status codes.
-You can access the **Requests** page by clicking "Requests" in the sidebar, under "Insights". The **Performance** page also shows the most time-consuming outgoing HTTP request domains in the "Most Time-Consuming Domains" widget. From there, you can click "View All" to open the **Requests** page.
+You can access the **Requests** page by clicking "Requests" in the sidebar, under "Sentry Dashboards". The **Performance** page also shows the most time-consuming outgoing HTTP request domains in the "Most Time-Consuming Domains" widget. From there, you can click "View All" to open the **Requests** page.
At the top of the page, there are three graphs that summarize the overall behavior of outgoing HTTP requests: a requests per minute (throughput) chart, an average duration chart, and a chart that shows the percentage of 3xx, 4xx, and 5xx HTTP response status codes. You can click and drag to select a specific time range directly in a graph.
diff --git a/includes/performance-metrics-definitions.mdx b/includes/performance-metrics-definitions.mdx
new file mode 100644
index 0000000000000..c10b04d6787ae
--- /dev/null
+++ b/includes/performance-metrics-definitions.mdx
@@ -0,0 +1,57 @@
+### Apdex
+
+Apdex is an industry-standard metric used to track and measure user satisfaction based on your application response times. A higher Apdex score is better than a lower one; the score can go up to 1.0, representing 100% of users having a satisfactory experience. The Apdex score provides the ratio of satisfactory, tolerable, and frustrated requests in a specific transaction or endpoint.
+
+- **T**: Threshold for the target response time.
+- **Satisfactory**: Page load times less than or equal to T.
+- **Tolerable**: Greater than T and less than or equal to 4T.
+- **Frustrated**: Greater than 4T.
+- **Formula**: (Satisfactory + (Tolerable/2)) / Total Requests
+
+Configure the satisfactory response time threshold (ms) in **Settings > Performance** per project, or override at the transaction level in **Transaction Summary > Settings** ([custom thresholds](#custom-thresholds)).
+
+### Failure Rate
+
+`failure_rate()` indicates the percentage of unsuccessful transactions. Sentry treats transactions with a status other than "ok," "cancelled," and "unknown" as failures. See [possible status values](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/span/).
+
+### Throughput (Total, TPM, TPS)
+
+Throughput is the number of transactions over a given time range (Total), average transactions per minute (TPM), or average transactions per second (TPS).
+
+### Latency
+
+#### Average Transaction Duration
+
+Average transaction duration is the average response time for all occurrences of a given transaction. Sentry aggregates durations with percentiles (p50, p75, p95, p99, p100) and maximum. With [sampled tracing](/product/sentry-basics/tracing/distributed-tracing/#data-sampling), averages and percentiles can be directionally correct but not exact; small sample sizes affect percentiles more than averages.
+
+#### P50 Threshold
+
+The p50 (median) is the value at which 50% of transaction durations are slower than this value.
+
+#### P75 Threshold
+
+The p75 is the value at which 25% of transaction durations are slower than this value.
+
+#### P95 Threshold
+
+The p95 is the value at which 5% of transaction durations are slower than this value.
+
+#### P99 Threshold
+
+The p99 is the value at which 1% of transaction durations are slower than this value.
+
+### User Misery
+
+User Misery counts the number of unique users who were frustrated (response time greater than four times the satisfactory threshold). It highlights transactions with the highest user impact. The calculation uses a probability distribution to avoid false positives at low volume. Set the satisfactory threshold in [custom thresholds](#custom-thresholds). In Discover, use the `count_miserable()` function to query the underlying data.
+
+### Time Spent
+
+Time Spent is the total cumulative time your application spends on a specific operation (e.g. database queries, API calls) over a given period — the sum of all durations, or average duration × rate. It indicates relative performance impact (e.g. 240ms average × 10,000 calls/hour ≈ 40 minutes time spent).
+
+### Custom Thresholds
+
+For each project, configure how [Apdex](#apdex) and [User Misery](#user-misery) are calculated in your project's [Performance settings](https://sentry.io/orgredirect/organizations/:orgslug/settings/projects/:projectId/performance/). You can override project-level settings at the transaction level in **Transaction Summary > Settings**. The response time threshold (ms) defines the satisfactory baseline; the calculation method can use full transaction duration or a [Web Vital](/product/dashboards/sentry-dashboards/frontend/web-vitals/) such as LCP.
+
+### Custom Performance Measurements
+
+
diff --git a/redirects.js b/redirects.js
index f6e1209652227..2aaa6d4c99eb9 100644
--- a/redirects.js
+++ b/redirects.js
@@ -1342,6 +1342,14 @@ const userDocsRedirects = [
source: '/product/insights/retention-priorities/',
destination: '/organization/dynamic-sampling/',
},
+ {
+ source: '/product/insights/overview/metrics/',
+ destination: '/product/dashboards/sentry-dashboards/transaction-summary/',
+ },
+ {
+ source: '/product/dashboards/sentry-dashboards/performance-metrics/',
+ destination: '/product/dashboards/sentry-dashboards/transaction-summary/',
+ },
// End of Insights reduirects.
{
source: '/platforms/javascript/guides/astro/manual-setup/',