Skip to main content

Available metrics in Insights

Abstract

There are numerous available metrics in Insights, such as build success rate, the number of builds, the median time of a successful builds, etc.

Insights allows you to track three categories of metrics:

  • Build metrics.

  • Test metrics.

  • Credits usage.

Build metrics

You can access build metrics from the charts on the Overview page or by selecting Builds on the left. The build metrics are available on app-, Pipeline, Stage, Workflow-, and Step level as well:

  • Top build time (p90): The 90th percentile of build times of successful builds. In other words, out of 100 successful builds, the 90th slowest build took this long. This metric is calculated based on your Pipelines' run time if you don't have any filters selected.

  • Typical build time (p50): The median time of a successful build. In other words, out of 100 successful builds, the 50th slowest build took this long. This metric is calculated based on your Pipelines' run time if you don't have any filters selected.

  • Failure rate: The rate of failed builds, or the rate at which a given Workflow failed. For example, if a Workflow failed six times out of ten, its failure rate is 60%. This metric is calculated based on your Pipelines' failure rate if you don't have any filters selected.

  • Build count: The total number of builds started of the app or Workflow, based on the filters and the timeframe you set.

  • Total duration: The total duration of all builds of the app or Workflow, based on the filters and the timeframe you set.

Test metrics

Access testing metrics by selecting Tests on the left. Similarly to basic build metrics, you can apply filters to test runs: you can filter for individual test suites, test cases, or modules, as well as to branches of your app's repository.

  • Top duration (p90): The 90th percentile of a test suite or a test case duration. If you filter on a specific test case, `Top duration (p90)` shows the 90th percentile duration of the specific test case. Otherwise, it shows the 90th percentile duration of the test suite(s) of the app or Workflow, based on the filters and the timeframe you set. 90th percentile means that out of 100 successful test executions, the 90th slowest took this much time to finish.

  • Typical duration (p50): The median (50th percentile) of a test suite or a test case duration. If you filter on a specific test case, `Typical duration (p50)` shows the 50th percentile duration of the specific test case. Otherwise, it shows the 50th percentile duration of the test suite(s) of the app or Workflow, based on the filters and the timeframe you set. 50th percentile means that out of 100 successful test executions, the 50th slowest took this much time to finish.

  • Failure rate: Test failure rate shows you how frequently a test suite or test case fails. For example, if you performed the test suite or test case 100 times, if 10 out of 100 failed, that's a 10% failure rate. If you filter on a specific test case, `Failure rate` shows the failure rate of the specific test case. Otherwise, it shows the failure rate of the test suite(s) of the app or Workflow based on the filters and the timeframe you set.

  • Total duration: The total duration of all tests of the app or Workflow, based on the filters and the timeframe you set.

  • Test runs: The total number of test runs.

  • Flaky runs: The number of test runs that produce inconsistent results despite no changes in the code.

Credits usage

Insights tracks the amount of credits used on each app and, if you need it, each Workflow of a given app. To check your usage, open Insights and on the left, select Credits.

The Credit usage chart shows the total credit usage of the app or Workflow, based on the filters and the timeframe you set.

In this section:

An app on Bitrise represents a Git repository that stores source code and has been connected to Bitrise to be able to run builds on it. As such, a Bitrise app isn't necessarily an actual application: it's just the code on which you run builds with Bitrise.

A Bitrise Pipeline is the top level of the Bitrise CI/CD configuration. Pipelines can be used to organize the entire CI/CD process and to set up advanced configurations with multiple different tasks running parallel and/or sequentially.

A Stage is a collection of Workflows. Stages are the top-level building blocks of Pipelines. A Stage can contain multiple Workflows, which all run in parallel in the same Stage. If all Workflows are successful in a Stage, the Pipeline moves on to the next Stage. If any of the Workflows fail, the Pipeline ends without running the other Stages unless you configure a given Stage to always run.

A Workflow is a collection of Steps, Environment Variables, and other configurations. When Bitrise starts a build, it runs one or more Workflows according to the configuration defined in the bitrise.yml file.

A Step is a block of script execution that encapsulates a build task on Bitrise: the code to perform that task, the inputs and parameters you can define for the task, and the outputs the task generates.