For the complete documentation index, see llms.txt. This page is also available as Markdown.

Device Metrics

Overview

Device Metrics gives real-time performance observability layer inside every test execution report. When enabled, it appears as a dedicated Device Metrics tab alongside the standard report tabs.

The tab captures hardware and runtime telemetry directly from the device during execution - CPU, memory, battery, network, and rendering performance, and surfaces it as threshold alerts, trend charts, and a step-by-step breakdown. This makes it possible to spot performance regressions, correlate spikes with specific test steps, and track app health across test plan runs without leaving the report.

Note: Device Metrics is currently supported for Android only.


Enabling Device Metrics

Device Metrics is off by default. To enable it for a test plan:

  1. Open the test plan configuration

  2. In the execution settings, Toggle App Performance Analysis to enabled before launching the run.

Once enabled, the Device Metrics tab appears in all subsequent execution reports for that test plan.


Performance Thresholds

At the top of the Device Metrics tab, a row of metric cards summarises the peak and average readings recorded during the execution.

Metric
What It Shows

Peak System CPU

Highest system-wide CPU usage observed, with the session average

Peak Memory

Highest app memory consumption (MB), with the session average

Bottom (Battery)

Battery drain recorded; shows drain percentage and scale

Peak Network

Highest network throughput observed; includes cumulative Rx and Tx values

Peak Janky Frames

Highest janky frame percentage recorded, with the total jank frame count average

These cards give you a health summary before you dive into the detailed alert and chart sections below.

Benchmarks

Benchmarks define the thresholds that determine when an alert fires and at what severity level.

Benchmarks apply across every test plan. You can customise the default thresholds to match your app's specific performance targets.


Alert Summary

The Alert Summary section reports the total number of threshold breaches detected across the entire execution, grouped by severity:

Severity
Colour
Meaning

Critical

Red

Threshold exceeded significantly; likely to affect user experience or stability

Warning

Yellow

Threshold exceeded moderately; worth investigating

Info

Blue/Grey

Threshold reached within an acceptable range; flagged for awareness

Each breach is displayed as an expandable alert card below the summary counts.

Alert Cards

Every alert card includes a description of the breach, the measured value, and the threshold it violated. Example alerts include:

  • High app CPU detected - App CPU reached or exceeded the critical threshold in a measured percentage of samples. Shows peak app CPU, average app CPU, and overage percentage.

  • Elevated system CPU detected - System CPU was between defined warning and critical bands across a percentage of measured steps.

  • App startup time above 3s - Application reached its fully drawn state in more than 3 seconds, indicating heavy initialisation work on the main thread or slow runtime at startup.

  • Moderate system CPU detected - System CPU was between warning bands across a percentage of measured steps; shows highest observed and average values.

  • Moderate app CPU detected - App CPU was between moderate thresholds across measured samples.

  • Moderate app memory usage detected - Memory consumption reached a moderate threshold during execution.


Visualize Metrics

The Visualize Metrics section renders time-series charts for each telemetry signal collected during the run. Use the tab bar to switch between signals:

Tab
Signal

CPU

App CPU and System CPU usage over time

Memory

App memory consumption (MB) over time

Janky Frames

Janky frame percentage per interval

Battery

Battery drain over time

Network

Network download and upload throughput over time

Each chart plots the metric against the execution timeline. Hover over any data point to see the exact value and timestamp.

Janky Frames note: The chart shows Janky Frame % (frames that missed their render deadline as a percentage of total frames), giving a more meaningful signal than raw frame counts.

Correlating Signals

Signals in different tabs can be related. Some common correlations to look for:

  • High network download activity often coincides with spikes in System CPU usage

  • High System CPU usage can accelerate battery drain

  • High FPS rendering load (janky frames) can contribute to elevated App CPU

Use the timeline as a shared axis - a spike in one chart at a given timestamp maps directly to the same point in other charts.


Step Details

The Step Details panel on the right side of the Device Metrics tab ties the performance data back to individual test steps. As you review the charts, the panel shows a device screenshot corresponding to the selected point in the execution, so you can see exactly what was happening on screen when a metric spike or threshold breach occurred.

This makes it straightforward to identify which test step or user interaction triggered a performance issue.

Last updated