debian-mirror-gitlab/doc/user/analytics/index.md

stage	group	info
Plan	Optimize	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

Analyze GitLab usage (FREE)

Instance-level analytics

Instance-level analytics make it possible to aggregate analytics across GitLab, so that users can view information across multiple projects and groups in one place.

Learn more about instance-level analytics.

Group-level analytics

Moved to GitLab Premium in 13.9.

GitLab provides several analytics features at the group level. Some of these features require you to use a higher tier than GitLab Free.

• Application Security
• Contribution
• DevOps Adoption
• Insights
• Issue
• Productivity
• Repositories
• Value Stream

Project-level analytics

You can use GitLab to review analytics at the project level. Some of these features require you to use a higher tier than GitLab Free.

• Application Security
• CI/CD
• Code Review
• Insights
• Issue
• Merge Request, enabled with the project_merge_request_analytics feature flag
• Repository
• Value Stream

User-configurable analytics

The following analytics features are available for users to create personalized views:

• Application Security

Be sure to review the documentation page for this feature for GitLab tier requirements.

DevOps Research and Assessment (DORA) key metrics (ULTIMATE)

• Introduced in GitLab 13.7.
• Added support for lead time for changes in GitLab 13.10.

The DevOps Research and Assessment (DORA) team developed several key metrics that you can use as performance indicators for software development teams.

Deployment frequency

Deployment frequency is the frequency of successful deployments to production (hourly, daily, weekly, monthly, or yearly). This measures how often you deliver value to end users. A higher deployment frequency means you can get feedback sooner and iterate faster to deliver improvements and features. GitLab measures this as the number of deployments to a production environment in the given time period.

Deployment frequency displays in several charts:

• Group-level value stream analytics
• Project-level value stream analytics
• CI/CD analytics

To retrieve metrics for deployment frequency, use the GraphQL or the REST APIs.

Lead time for changes

DORA Lead time for changes measures the time to successfully deliver a feature into production. This metric reflects the efficiency of CI/CD pipelines.

In GitLab, Lead time for changes calculates the median time it takes for a merge request to get merged into production. We measure "FROM code committed TO code successfully running in production" without adding the "coding_time" to the calculation.

Over time, the lead time for changes should decrease, while your team's performance should increase.

Lead time for changes displays in several charts:

• Group-level value stream analytics
• Project-level value stream analytics
• CI/CD analytics

To retrieve metrics for lead time for changes, use the GraphQL or the REST APIs.

• The definition of lead time for change can vary widely, which often creates confusion within the industry.
• "Lead time for changes" is not the same as "Lead time". In the value stream, "Lead time" measures the time it takes for work on issue to move from the moment it's requested (Issue created) to the time it's fulfilled and delivered (Issue closed).

Time to restore service

Time to restore service measures how long it takes an organization to recover from a failure in production. GitLab measures this as the average time required to close the incidents in the given time period. This assumes:

• All incidents are related to a production environment.
• Incidents and deployments have a strictly one-to-one relationship. An incident is related to only one production deployment, and any production deployment is related to no more than one incident).

Time to restore service displays in several charts:

• Group-level value stream analytics
• Project-level value stream analytics
• CI/CD analytics

To retrieve metrics for time to restore service, use the GraphQL or the REST APIs.

Change failure rate

Change failure rate measures the percentage of deployments that cause a failure in production. GitLab measures this as the number of incidents divided by the number of deployments to a production environment in the given time period. This assumes:

• All incidents are related to a production environment.
• Incidents and deployments have a strictly one-to-one relationship. An incident is related to only one production deployment, and any production deployment is related to no more than one incident.

To retrieve metrics for change failure rate, use the GraphQL or the REST APIs.

Supported DORA metrics in GitLab

Metric	Level	API	UI chart	Comments
deployment_frequency	Project	GitLab 13.7 and later	GitLab 14.8 and later	The previous API endpoint was deprecated in 13.10.
deployment_frequency	Group	GitLab 13.10 and later	GitLab 13.12 and later
lead_time_for_changes	Project	GitLab 13.10 and later	GitLab 13.11 and later	Unit in seconds. Aggregation method is median.
lead_time_for_changes	Group	GitLab 13.10 and later	GitLab 14.0 and later	Unit in seconds. Aggregation method is median.
time_to_restore_service	Project and group	GitLab 14.9 and later	GitLab 15.1 and later	Unit in days. Aggregation method is median.
change_failure_rate	Project and group	GitLab 14.10 and later	GitLab 15.2 and later	Percentage of deployments.

Definitions

We use the following terms to describe GitLab analytics:

• Mean Time to Change (MTTC): The average duration between idea and delivery. GitLab measures MTTC from issue creation to the issue's latest related merge request's deployment to production.
• Mean Time to Detect (MTTD): The average duration that a bug goes undetected in production. GitLab measures MTTD from deployment of bug to issue creation.
• Mean Time To Merge (MTTM): The average lifespan of a merge request. GitLab measures MTTM from merge request creation to merge request merge (and closed/un-merged merge requests are excluded). For more information, see Merge Request Analytics.
• Mean Time to Recover/Repair/Resolution/Resolve/Restore (MTTR): The average duration that a bug is not fixed in production. GitLab measures MTTR from deployment of bug to deployment of fix.
• Velocity: The total issue burden completed in some period of time. The burden is usually measured in points or weight, often per sprint. For example, your velocity may be "30 points per sprint". GitLab measures velocity as the total points or weight of issues closed in a given period of time.