diff --git a/assets/images/analytics/app-profiling-comparison-filters.webp b/assets/images/analytics/app-profiling-comparison-filters.webp new file mode 100644 index 000000000..5820f7ded Binary files /dev/null and b/assets/images/analytics/app-profiling-comparison-filters.webp differ diff --git a/assets/images/analytics/app-profiling-comparison-startup.webp b/assets/images/analytics/app-profiling-comparison-startup.webp new file mode 100644 index 000000000..9af48f8a5 Binary files /dev/null and b/assets/images/analytics/app-profiling-comparison-startup.webp differ diff --git a/assets/images/analytics/app-profiling-comparison.webp b/assets/images/analytics/app-profiling-comparison.webp new file mode 100644 index 000000000..3c908a07e Binary files /dev/null and b/assets/images/analytics/app-profiling-comparison.webp differ diff --git a/assets/images/analytics/app-profiling-email-alert.png b/assets/images/analytics/app-profiling-email-alert.png new file mode 100644 index 000000000..c830b6f03 Binary files /dev/null and b/assets/images/analytics/app-profiling-email-alert.png differ diff --git a/assets/images/analytics/app-profiling-slack-alert.png b/assets/images/analytics/app-profiling-slack-alert.png new file mode 100644 index 000000000..64e248e39 Binary files /dev/null and b/assets/images/analytics/app-profiling-slack-alert.png differ diff --git a/docs/analytics-insights-app-profiling.md b/docs/analytics-insights-app-profiling.md index dc313d504..e87fbec19 100644 --- a/docs/analytics-insights-app-profiling.md +++ b/docs/analytics-insights-app-profiling.md @@ -2,14 +2,21 @@ id: insights-app-profiling title: App Profiling Insights sidebar_label: App Profiling -description: Discover TestMu AI's App Profiling Insights for comprehensive test cases insights. Optimize your testing efforts today. +description: App Profiling Insights surface CPU, memory, frame rate, battery, network, disk and startup metrics across devices, builds and page transitions, with Average and p90 views, session-level Comparison against a baseline run, org-level SLA thresholds, saved filters and email/Slack breach alerts. keywords: - analytics - test insights - - App Profiling - - Desktop insights - - Desktop trends - - Desktop status ratio + - app profiling + - mobile app performance + - cpu memory fps insights + - device performance matrix + - page load time + - sla thresholds + - p90 metrics + - disk read write + - threshold breach alerts + - session comparison + - baseline diff url: https://www.testmuai.com/support/docs/insights-app-profiling/ site_name: LambdaTest @@ -37,7 +44,7 @@ import BrandName, { BRAND_URL } from '@site/src/component/BrandName'; },{ "@type": "ListItem", "position": 3, - "name": "Linear App Integration", + "name": "App Profiling Insights", "item": `${BRAND_URL}/support/docs/insights-app-profiling/` }] }) @@ -50,242 +57,280 @@ import NewTag from '../src/component/newTag'; ## Overview -The App Profiling dashboard provides comprehensive performance metrics to help you identify bottlenecks and optimize your application. This documentation explains each widget's purpose and how to interpret the data to improve app performance. +The App Profiling dashboard aggregates performance telemetry from Appium tests run with the `appProfiling` capability and surfaces it as cross-test, cross-device analytics. Use it to compare CPU, memory, frame rate, battery, network and startup behaviour across devices, app builds and page transitions, with org-level SLA thresholds rendered directly on each chart. -cmd +The data on this dashboard comes from the App Profiling capability on Appium tests. To enable App Profiling on your test runs and review per-session metrics, see [App Performance Analytics](/support/docs/appium-app-performance-analytics/). -## Understanding Performance Metrics Widgets +:::note +App Profiling Insights is available for Appium tests on iOS and Android (version 9+). Set `appProfiling: true` and `resignApp: true` in your capabilities. Battery Utilization and Battery Temperature widgets are populated for Android sessions only. +::: -### CPU Utilization Trend +App Profiling dashboard -**Widget Purpose:** -This graph tracks CPU consumption over time, separating system-level processing from app-specific usage. +## How to access -**Metrics Explained:** -- **CPU System (%)**: Total system CPU resources being used -- **CPU App (%)**: CPU resources specifically consumed by your application - -**How to Analyze:** -- Look for consistent app CPU usage above 15-20%, which may indicate inefficient algorithms or background tasks -- Watch for correlations between high CPU usage and other performance issues -- Identify patterns: gradual increases could signal memory leaks; sudden spikes might indicate intensive operations +1. Open the **Insights** section from the left sidebar of the dashboard. +2. Select **App Profiling**. The landing page lists every test that has App Profiling data. +3. Click a test name to open its dashboard. -**Optimization Strategies:** -- Offload intensive tasks to background threads -- Implement lazy loading for resource-heavy features -- Use caching mechanisms for repetitive operations -- Optimize algorithms with high computational complexity -- Consider using more efficient data structures +The page is always scoped to the test you opened. Use the **Test Name** filter to add more tests to the comparison without leaving the dashboard. -### Frame Rate Trends +The dashboard opens on two tabs: -**Widget Purpose:** -Visualizes rendering performance, highlighting both smooth operation and problematic frames. +- **Trends** — the aggregated view described below: KPI cards, trend widgets and the device matrix, averaged across every session in the filtered scope. +- **[Comparison](#comparison)** — an overlay view that plots individual test sessions against one another, run by run. -**Metrics Explained:** -- **Current FPS**: Frames rendered per second (higher is better, 60+ ideal for smooth animation) -- **Jank Frames**: Frames taking excessive time to render, causing visual stuttering -- **Frozen Frames**: Completely dropped frames that cause noticeable pauses +## Filter bar -**How to Analyze:** -- Identify sections where FPS consistently drops below target (60 FPS for most applications) -- Pay attention to clusters of jank frames, which indicate UI thread blockage -- Look for correlations between frozen frames and specific user interactions +The filter bar at the top of the dashboard applies to every widget on the page. -**Optimization Strategies:** -- Move heavy operations off the UI thread -- Simplify complex layouts and view hierarchies -- Reduce overdraw by flattening view layers -- Optimize or defer expensive drawing operations -- Implement hardware acceleration where appropriate -- Use profiling tools to identify specific rendering bottlenecks +| Filter | Values | Default | +|---|---|---| +| **Test Name** | Multi-select, up to 25 tests | The test you opened (pre-selected) | +| **OS** | Android, iOS | All | +| **Device** | Specific device models recorded across the selected tests | All | +| **App Build Version** | Build versions captured during the sessions | All | +| **Page Label** | Page transition labels recorded by the test | All | +| **Date Range** | Preset windows or a custom range with a time-of-day picker | Last 30 days | -### Memory Usage +Each filter is a searchable multi-select; changes take effect when you click **Apply**, and **Reset** clears that single filter. The **OS**, **Device**, **App Build Version** and **Page Label** dropdowns only list values present in the currently selected **Test Name(s)**, so you never see options that would return no data. -**Widget Purpose:** -Monitors memory allocation patterns to identify potential leaks and inefficient resource usage. - -**Metrics Explained:** -- **App Memory (MB)**: Direct memory consumed by your application -- **System Memory (MB)**: Overall system memory usage - -**How to Analyze:** -- Look for steadily increasing app memory over time (indicates potential leaks) -- Identify memory spikes during specific operations -- Pay attention to how memory behaves after screen transitions or intensive tasks -- Watch for memory that doesn't return to baseline after operations complete +Clearing the Test Name filter and clicking Apply restores the test you opened — the dashboard is never scoped to zero tests. -**Optimization Strategies:** -- Implement proper object lifecycle management -- Use weak references for observer patterns -- Optimize image loading and caching -- Dispose of resources when moving between screens -- Consider using object pools for frequently created/destroyed objects -- Implement memory leak detection in development builds +### Saved filters -### Battery Utilization - -**Widget Purpose:** -Tracks energy consumption to identify processes that may drain battery excessively. +Your filter selections, the selected date range, and the widget layout — including any widgets you resize — are **auto-saved at the organisation level**. There is no Save button: when you refresh the page or return to the dashboard later, it reopens with your last-used filters, date range and layout already applied. Use the **Clear All Filters** button to reset everything back to the defaults. The KPI and Compare selections made inside individual widgets are not persisted. -**Metrics Explained:** -- **Battery (mAh)**: Energy consumption rate in milliampere-hours +## Average and p90 views -**How to Analyze:** -- Identify patterns of high battery usage -- Look for correlation between battery drain and specific app features -- Compare battery usage across different app states (active, background, idle) +An **Average / p90** toggle in the top bar of the **Trends** tab switches its widgets between two aggregations: -**Optimization Strategies:** -- Optimize network calls (batch requests, compress data) -- Reduce location service usage when not essential -- Implement efficient background processing -- Optimize wake locks and sensor usage -- Use dark mode or darker UI for OLED screens -- Batch CPU-intensive operations +- **Average** — the mean value of each metric across the sessions in scope. +- **p90** — the 90th-percentile value: the level at or below which 90% of sessions fall. -### Network Utilization +Switching to **p90** re-renders the Performance Overview cards, Performance Trends, the per-metric trend widgets and the Device Performance Matrix using the 90th-percentile value for every metric. The same p90 values are also available through the App Profiling API. -**Widget Purpose:** -Monitors data transfer to identify inefficient network operations. +### Which one to read -**Metrics Explained:** -- **Network Upload (KB)**: Data sent by the application -- **Network Download (KB)**: Data received by the application +Average answers *"what does a typical run cost?"*. p90 answers *"how bad does it get for the unlucky one run in ten?"*. They are complementary, and a metric can look healthy on one and fail on the other. -**How to Analyze:** -- Look for unexpected or excessive data transfers -- Identify patterns in network activity (constant polling vs. event-based) -- Compare network usage against expected data requirements +| Read | When you are | +|---|---| +| **Average** | Tracking a trend over time, comparing builds or devices at a glance, or reporting a headline number | +| **p90** | Investigating a regression, sizing an SLA, or explaining complaints that the dashboard's averages don't reflect | -**Optimization Strategies:** -- Implement efficient caching strategies -- Compress network payloads -- Use incremental data loading -- Optimize API requests (GraphQL, partial responses) -- Batch network requests when possible -- Implement offline capabilities -- Use efficient image formats and compression +Averages hide spikes. A build whose CPU averages 12% but reaches 45% on every tenth run will look green on Average and breach on p90 — and it is the p90 run your users notice. The reverse is also informative: if Average and p90 sit close together, the metric is stable and the average is trustworthy. -### App Temperature +:::note +p90 is computed per session at ingestion and then averaged across the sessions in scope — it is *the mean of each session's own 90th percentile*, not the 90th percentile of the whole window. Metrics with no pre-computed p90 — cold and hot startup, and the crash and ANR counts — are dropped in p90 mode and render as `—`. Frozen and janky frame counts stay on their average, because they are companion counts to the frame-rate series rather than percentile-able metrics in their own right. +::: -**Widget Purpose:** -Measures device thermal performance to identify processes causing overheating. +### p90 on the Comparison tab -**Metrics Explained:** -- **Avg. Temperature (°C)**: Current average temperature of the device +The Comparison tab has **no Average / p90 toggle** — the Trends toggle does not carry across, and switching tabs will not change what Comparison shows. -**How to Analyze:** -- Track temperature increases during specific operations -- Identify features that consistently raise device temperature -- Look for sustained high temperatures that could lead to thermal throttling +It does not need one: every stats table on that tab reports **Avg, Min, Max and P90 side by side, always**, for each selected session. Where the Trends toggle makes you choose one aggregation for the whole dashboard, Comparison shows you all four at once for the handful of runs you have selected — which is the more useful shape when you are looking at individual runs rather than a population. -**Optimization Strategies:** -- Optimize CPU-intensive algorithms -- Reduce sustained high CPU/GPU operations -- Space out intensive tasks rather than running simultaneously -- Implement adaptive performance based on device temperature -- Consider lower quality graphics or processing when temperature is high +{/* TODO screenshot: top bar showing the Average / P90 toggle, date range and Export As — save as assets/images/analytics/app-profiling-p90-toggle.png and embed here */} -### Cold Startup Time +## Performance Overview -**Widget Purpose:** -Measures application launch performance from a completely shut down state. +A strip of KPI cards summarising the headline metrics over the selected window. -**Metrics Explained:** -- **Cold Startup (ms)**: Time taken to launch app when not in memory +- **Avg CPU (%)** — application CPU usage averaged across sessions in scope. +- **Avg Memory (MB)** — application memory usage averaged across sessions in scope. +- **Avg FPS** — frames per second averaged across sessions in scope. +- **Avg Cold Startup (ms)** — cold-start duration averaged across sessions in scope. -**How to Analyze:** -- Look for consistently high startup times -- Identify variations in startup performance -- Compare against industry benchmarks (1-2 seconds is typically acceptable) +When sessions in the selected scope record crashes or ANRs, two additional cards surface: -**Optimization Strategies:** -- Implement lazy initialization of non-critical components -- Defer heavy operations until after UI is visible -- Optimize database and storage access during startup -- Use app startup libraries to manage initialization -- Consider using a splash screen for perceived performance -- Reduce app dependencies and initialization chain +- **Avg Crashes per Crashed Session** — `avg(crash_count)` over sessions that reported at least one crash. This is the mean crash count among already-crashed sessions, not a crash rate. +- **Avg ANRs per ANR Session** — equivalent for Application Not Responding events. -### Hot Startup Time +Cards are hidden automatically when the underlying metric reports zero for the filtered scope. -**Widget Purpose:** -Measures application launch performance when re-opening from background. +## Performance Trends -**Metrics Explained:** -- **Hot Startup (ms)**: Time taken to resume app when already in memory +A single time-series chart that overlays selected metrics on dual Y-axes. The **KPIs** selector in the widget header controls which series are visible — CPU, FPS, Memory, Temperature, Battery, Network Upload, Network Download, Disk Read and Disk Write are available; CPU and Memory are on by default. Each visible KPI gets a Min / Max / Avg row in the stats panel below the chart. -**How to Analyze:** -- Look for hot startup times exceeding 500ms -- Identify inconsistency in resume performance -- Compare against cold startup to ensure significant improvement +**Disk Read** and **Disk Write** report the total data the application read from and wrote to disk during a session, giving visibility into storage-heavy workflows. Like every other metric, they honour the Average / p90 toggle. -**Optimization Strategies:** -- Optimize saved state management -- Implement efficient view restoration -- Use lightweight persistence mechanisms -- Consider UI state caching strategies -- Prioritize restoring visible elements first +The X-axis bucket size is derived from the selected date range — sub-day windows render at 5-minute or 15-minute buckets, multi-week windows aggregate to hours, and multi-month windows aggregate to days. -## Advanced Analysis Techniques +{/* TODO screenshot: Performance Trends KPI selector open, showing the full metric list including Disk Read / Disk Write — save as assets/images/analytics/app-profiling-kpi-metrics.png and embed here */} -### Correlation Analysis +## Device Performance Matrix -To gain deeper insights, analyze relationships between different metrics: +A table comparing performance metrics across the devices that ran in the filtered scope. One row per device. -1. **CPU vs. Frame Rate**: High CPU often correlates with frame drops -2. **Memory vs. Startup Time**: Increasing memory usage may slow startup -3. **Battery vs. Network**: Excessive network activity typically increases battery consumption -4. **Temperature vs. Performance**: High temperatures often lead to throttling and reduced performance +| Column | Description | +|---|---| +| **Device** | Device model | +| **CPU App (%)** | Application CPU usage, colour-coded against the configured SLA threshold | +| **CPU System (%)** | System-level CPU usage | +| **Memory App (MB)** | Application memory, colour-coded against the configured SLA threshold | +| **Memory System (MB)** | System-level memory | +| **FPS** | Frame rate, colour-coded against the configured SLA threshold | +| **Sessions** | Session count for that device in the filtered scope | -### Benchmark Comparison +Click any column header to sort. The dashboard-level **Device** filter intentionally does not narrow this widget — the matrix is itself the device breakdown. -Establish baseline metrics for your application: +## Label Page Load Time -1. **Competitor Analysis**: Compare your metrics against similar apps -2. **Version Comparison**: Track metrics across your app versions -3. **Device Variation**: Compare performance across different device models -4. **User Scenario Testing**: Create specific user flows and measure performance +Duration per page transition label, captured from the `label` events recorded inside the test. The widget shows the top labels by session count by default; use the label selector inside the widget to add or remove labels from the chart. -### Performance Budgeting +A horizontal SLA reference line is drawn at the configured threshold. The stats panel below the chart reports Min / Max / Avg duration per visible label. -Set target thresholds for critical metrics: +## Per-metric trend widgets -1. **Startup Budget**: Cold start < 2 seconds, hot start < 500ms -2. **Frame Rate Budget**: Maintain 60+ FPS during animations -3. **Memory Budget**: Keep peak memory under device-specific thresholds -4. **Network Budget**: Limit payload sizes and request frequency -5. **Battery Budget**: Limit battery consumption per hour of active use +Each of the eight per-metric widgets renders a time series over the selected window with the SLA threshold drawn as a coloured band, and reports Min / Max / Avg for the primary metric in the stats panel below the chart. -## Implementing Performance Improvements +| Widget | Metrics | Notes | +|---|---|---| +| **CPU Utilization Trend** | CPU App (%), CPU System (%) | — | +| **Frame Rate Trends** | Current FPS, Janky Frames, Frozen Frames | — | +| **Memory Usage** | App Memory (MB), System Memory (MB) | — | +| **Battery Utilization** | Battery drain (mAh) | Android only | +| **Network Utilization** | Network Upload (KB), Network Download (KB) | Separate SLA thresholds for upload and download | +| **Battery Temperature** | Temperature (°C) | Android only | +| **Cold Startup Time** | Cold Startup (ms) | — | +| **Hot Startup Time** | Hot Startup (ms) | — | -### Prioritization Framework +## Compare mode -When addressing performance issues: +Each per-metric trend widget and Label Page Load Time supports **Compare** mode. Click **Compare** in the widget header, pick a dimension, then select up to five values to overlay on the chart. -1. **User Impact**: Prioritize issues directly affecting user experience -2. **Frequency**: Address problems that occur most frequently -3. **Severity**: Focus on severe performance degradations first -4. **Complexity**: Balance effort required against potential improvements -5. **Business Impact**: Consider effects on retention, conversion, and engagement +Compare dimensions: -### Testing Methodology +- **OS** — Android vs iOS +- **Device** — for example Galaxy S23 vs Pixel 8 vs iPhone 15 Pro +- **App Build Version** — for build-over-build comparisons +- **Label** — for page-transition-level breakdowns -Verify improvements through rigorous testing: +Compare is scoped to the widget — enabling it on one chart does not affect others. Performance Overview, Performance Trends and Device Performance Matrix do not expose Compare: the first two are summary widgets (use filters to change the data scope instead), and the matrix already breaks data down per device. -1. **A/B Testing**: Compare metrics between old and new implementations -2. **Progressive Rollout**: Deploy changes to a small percentage of users first -3. **Real-World Testing**: Test across various network conditions and devices -4. **Automated Performance Testing**: Implement CI/CD performance checks +## Comparison -## Continuous Monitoring +The **Comparison** tab plots individual test sessions against one another instead of averaging them. Use it to answer run-level questions the Trends tab cannot: whether a build regressed against the run before it, whether one device is slower than another on the same app, or why a single run behaved differently from the rest. -For ongoing performance optimization: +Where the Trends tab charts a metric over calendar time, Comparison charts it over **elapsed time within each run** — every session starts at `0:00`, so runs of different lengths and different start times line up and can be read against each other. -1. **Real User Monitoring**: Collect performance data from production users -2. **Performance Regressions**: Set up alerts for metric degradations -3. **Periodic Audits**: Schedule regular performance reviews -4. **User Feedback Analysis**: Correlate performance metrics with user sentiment +App Profiling Comparison view with three test sessions overlaid -By leveraging these widgets and analysis techniques, you can systematically identify and address performance bottlenecks, resulting in a faster, more efficient, and battery-friendly application that provides an excellent user experience. +### Complete flow + +1. Open a test's App Profiling dashboard and select the **Comparison** tab. The **most recent** run of that test is selected automatically and becomes the baseline — note that this is the newest run, not necessarily the specific run you opened the dashboard from. +2. Narrow the **Test Sessions** rail on the left with the search box and filters until you can see the runs you care about. +3. Tick the checkbox on each session you want to overlay — up to **five** at a time. +4. Pick which run everything is measured against with **Set as Baseline**. +5. Read the charts and the per-metric stats tables. Leave **Baseline Diff.** on to see each session's delta against the baseline. +6. Drag on the timeline at the top to zoom into a slice of the run; every chart follows. + +### Test Sessions rail + +The rail lists every session that matches the current filters, with a running count in the header. Sessions you have selected for comparison are **pinned to the top** so they stay visible as you filter; everything else follows, newest first. Each card shows the pass/fail status, the test name, when it ran, a truncated Test ID, and the OS version, device and app build version it ran on. + +| Control | What it does | +|---|---| +| **Search test name** | Free-text filter over the listed session names | +| **Test Name** | Multi-select of test names. At least one must stay selected — **Apply** is disabled otherwise | +| **Date range** | The same picker the Trends tab uses, with presets and a custom range including a time-of-day picker | +| **More** | **OS**, **App Build Version**, **Device** and **Status** multi-selects | +| **Clear Filters** | Resets the filters back to the opened test and the comparison back to that test's most recent run. The date range is deliberately preserved — it belongs to the shared picker, not to this filter set | +| Checkbox | Adds or removes that session from the comparison | +| **Set as Baseline** | Makes that session the reference every other session is measured against | + +Test Sessions rail with the More filter menu open showing OS, App Build Version, Device and Status + +:::note +You can compare up to five sessions at once — deselect one to add another — and at least one session must stay selected, so the charts are never left empty. +::: + +### How the graphs are drawn + +Each metric renders as its own card, in this order: **CPU Utilization**, **Memory Utilization**, **Frame Rate**, **Disk**, **Network**, and **Startup Time**. + +- **One series per selected session**, coloured consistently across every card — a session keeps its colour everywhere, so you can follow one run down the page. +- **A shared elapsed-time X-axis.** Dragging on the **Comparison of Test Sessions** timeline at the top zooms every chart to the same window at once, which is what makes a spike in one metric comparable against another. +- **Legend toggles.** Click a session in a card's legend to hide or show that series in that card. The last visible series cannot be hidden. +- **Variant toggles** where a metric has more than one dimension: Application / System on CPU and Memory, Read / Write on Disk, Upload / Download on Network, and Startup Time / Load Time on the startup card. +- **SLA bands and threshold lines** are drawn from the same org-level thresholds used everywhere else on the dashboard. +- **A stats table** under every chart with **Avg**, **Min**, **Max** and **P90** per session — all four at once, with no toggle. See [p90 on the Comparison tab](#p90-on-the-comparison-tab). + +**Startup Time** is a grouped bar chart rather than a line — it reports one Cold and one Hot value per run, with the Cold and Hot SLA lines drawn across it. Its **Load Time** variant switches to per-page-label load times, plotted by label instead of by elapsed time. + +Startup Time comparison showing Cold and Hot bars per session with SLA lines and baseline deltas + +### Baseline and Baseline Diff + +One session is always the baseline, marked with a **Baseline** chip in the rail and in every stats table. + +With **Baseline Diff.** enabled — it is on by default — every other session's stats show a coloured delta against the baseline: green where the session is better, red where it is worse. The direction that counts as "better" follows the metric, so a lower CPU figure and a higher frame rate are both green. In the Startup Time screenshot above, the two non-baseline runs start `142 ms` and `94 ms` faster than the baseline's cold start. + +Turn **Baseline Diff.** off to read raw values with no deltas. + +### Saved comparisons + +Your Comparison setup is **auto-saved per test at the organisation level**, the same way the Trends tab saves its filters and layout. There is no Save button. Reopening the tab restores: + +- the rail filters — test names, OS, device, status and app build version, +- which sessions were selected for comparison, +- which session was the baseline, +- the **Baseline Diff.** toggle, +- any series you hid from a card's legend. + +The date range is not part of the saved comparison — it is owned by the page's date picker and shared with the Trends tab, so both tabs always report over the same window. + +## SLA thresholds + +SLA thresholds are configured at the **organisation level** by an admin. Once set, the same threshold is applied everywhere a metric is rendered — Performance Overview cards, Performance Trends overlays, Device Performance Matrix cells, Label Page Load Time, and the per-metric trend widgets. + +Default thresholds: + +| Metric | Green | Amber | Red | +|---|---|---|---| +| CPU (App) | < 15% | 15–30% | > 30% | +| Memory (App) | < 300 MB | 300–400 MB | > 400 MB | +| FPS | > 50 | 30–50 | < 30 | +| Cold Startup | < 2000 ms | 2000–3000 ms | > 3000 ms | +| Hot Startup | < 500 ms | 500–1000 ms | > 1000 ms | +| Battery Temperature | < 40 °C | 40–45 °C | > 45 °C | +| Label Page Load | < 2.5 s | 2.5–3.0 s | > 3.0 s | + +Thresholds render as: + +- Horizontal reference lines on trend charts. +- Coloured background bands behind the chart area. +- Cell-level heatmap colouring on Device Performance Matrix. +- Coloured value text on Performance Overview cards. + +Battery Utilization (mAh drain) is rendered without a threshold by default — drain varies widely by device hardware and there is no industry-standard band. + +:::note +Admins can override the defaults at the organisation level. Regular users see the configured thresholds applied but cannot modify them. +::: + +## Threshold breach alerts + +When a session breaches a configured App Profiling threshold, automatically notifies your team over **email** and **Slack** — so you can catch performance regressions without opening the dashboard after every run. + +Each alert identifies the run (Test ID, Test Name, Build Name, OS, Device and date) and lists every breached metric with its observed value against the configured threshold, along with a **View Test Details** link that opens the run's App Profiling tab. Metrics that can trigger an alert include Cold Startup, Hot Startup, CPU Utilization, Frame Rate, Memory Usage, Temperature and per-label Page Load. + +App Profiling threshold breach email alert + +The Slack notification carries the same details: + +App Profiling threshold breach Slack alert + +:::note +Alerts fire against the same SLA thresholds described above, which are configured at the organisation level by an admin. +::: + +## Sharing a dashboard + +The URL of the dashboard preserves the test it was opened against, and which of the two tabs you are on — a link copied from the Comparison tab reopens on Comparison. To share a specific view with a teammate, apply the filters you want and copy the URL — the shared dashboard opens with the same test in scope. Filter selections beyond Test Name are not round-tripped through the URL; they are restored from your own saved filters instead. + +## Related + +- [App Performance Analytics](/support/docs/appium-app-performance-analytics/) — how to enable App Profiling on Appium tests and review per-session metrics. +- [Analytics Overview](/support/docs/analytics-overview/) — the broader Insights module.