Performance Metrics

Sentry's SDKs support sending performance metrics data to Sentry. These are numeric values attached to transactions that are aggregated and displayed in Sentry.

If configured, the Android SDK automatically collects the following performance metrics:

Application Not Responding (ANR) errors are triggered when the main UI thread of an application is blocked for more than five seconds. When configured, Sentry's Android SDK reports ANR errors.

ANR rate is the percentage of unique users who have experienced an ANR during the specified time period.

User-perceived ANR rate is a core Android vital and is defined more specifically, as the unique percentage of users who've experienced the lack of response to an input event in an app, lasting more than five seconds.

A user-perceived ANR rate that's more than 0.47%, is considered over the bad behavior threshold, as set by Google. If your app exceeds this threshold, Google Play may choose to reduce your app’s visibility in their app store.

In Sentry, we can monitor the foreground ANR rate, which is the percentage of unique users who’ve experienced an ANR event lasting more than five seconds, while the app was running in the foreground. Because it’s more noticeable to the user, a foreground ANR event is more likely to be seen as an annoyance.

While foreground ANR rates may not map exactly to user-perceived ANR rates, they can provide a close proxy. In Sentry, the foreground ANR rate chart has a bad behavior threshold line for comparison.

To see your ANR rate in Sentry, go to the Projects page, click on your Android project, then look for the ANR rate card in the "Project Details" section. Clicking the "View Issues" button in the "ANR Rate" card will take you to a list of ANR issues that were created in the selected timeframe and environment.

You can also see an ANR rate graph on a separate card. Opening the "Display" menu will allow you to switch back and forth between the "ANR Rate" and the "Foreground ANR Rate" view.

Sentry's Android SDK, version 6.13.0 and above, reports ANR rate errors if the main UI thread of your application is blocked for more than five seconds.

In addition to automatic performance metrics, the SDK supports setting custom performance metrics on transactions. This allows you to define metrics that are important to your application and send them to Sentry.

To set a performance metric, you need to supply the following:

  • name (string)
  • value (any numeric type - float, integer, etc.)
  • unit (string, Defaults to the string none if omitted.)

Sentry supports adding arbitrary custom units, but we recommend using one of the supported units listed below.

Adding custom metrics is supported in Sentry's Java SDK, version 6.5.0 and above.

Copied
import io.sentry.ISpan;
import io.sentry.MeasurementUnit;
import io.sentry.Sentry;

final ISpan span = Sentry.getSpan();
if (span != null) {
    // Record amount of memory used
    span.setMeasurement("memory_used", 64, MeasurementUnit.Information.MEGABYTE);

    // Record time it took to load user profile
    span.setMeasurement("user_profile_loading_time", 1.3, MeasurementUnit.Duration.SECOND);

    // Record number of times the screen was loaded
    span.setMeasurement("screen_load_count", 4);
}

Units augment metric values by giving meaning to what otherwise might be abstract numbers. Adding units also allows Sentry to offer controls - unit conversions, filters, and so on - based on those units. For values that are unitless, you can supply an empty string or none.

  • nanosecond
  • microsecond
  • millisecond
  • second
  • minute
  • hour
  • day
  • week

  • bit
  • byte
  • kilobyte
  • kibibyte
  • megabyte
  • mebibyte
  • gigabyte
  • gibibyte
  • terabyte
  • tebibyte
  • petabyte
  • pebibyte
  • exabyte
  • exbibyte

  • ratio
  • percent

If you want to explore further, you can find details about supported units in our event ingestion documentation.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").