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 main categories of metrics. These are the metrics for your Bitrise builds that require no other integration: if you use Bitrise CI and Insights, you can track these metrics:

  • Build metrics.

  • Test metrics.

  • Utilization.

In addition, Insights can provide data for:

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 opening the main Insights page and 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.

Utilization metrics

Availability

The full utilization data described here is only available to users on a custom Enterprise plan. On other plans, you can only see your credit usage.

Access utilization metrics by opening the main Insights page and selecting Utilization on the left. The Utilization page shows the resources used for Bitrise builds, enabling efficient tracking of your costs.

By default, the page shows all metrics based on your billing cycle. This helps to track commitments and spending during a cycle without having to do any calculations of your own. The page also shows how much time remains of the current cycle. You can change this default frame of reference in the dropdown menu in the top right corner.

The Utilization page always shows your overall infrastructure utilization. This metric aggregates all your infrastructure utilization, including build minutes, cache storage, artifacts storage and network egress. The page compares this aggregate total to your total commitment, displaying both a monetary value and a percentage value.

  • Credit usage: Insights tracks the amount of credits used on each app and, if you need it, each Workflow of a given app.

  • Build minutes: Track how much time you spent building on the different machine types, enabling efficient tracking of computing resource consumption. You can set filters to show the data on multiple levels: build minutes per app, Pipeline, Stage, or Workflow.

  • Cache storage: This is only relevant if you use the remote build cache feature. It shows how much storage space your cache archives take up.

  • Artifacts storage: It shows how much storage space your generated artifacts take up.

  • Network egress: Data transfer from the build cache to external networks or clients to retrieve build artifacts. This includes data downloaded to a local development environment or to any other CI environment other than Bitrise.

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.