info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
We use the following terms to describe GitLab analytics:
- **Cycle time:** The duration of only the execution work. Cycle time is often displayed in combination with the lead time, which is longer than the cycle time. GitLab measures cycle time from the earliest commit of a [linked issue's merge request](../project/issues/crosslinking_issues.md) to when that issue is closed. The cycle time approach underestimates the lead time because merge request creation is always later than commit time. GitLab displays cycle time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](../analytics/value_stream_analytics.md).
- **Deploys:** The total number of successful deployments to production in the given time frame (across all applicable projects). GitLab displays deploys in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](value_stream_analytics.md).
- **DORA (DevOps Research and Assessment)** ["Four Keys"](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance):
- **Speed/Velocity**
- **Deployment frequency:** The relative frequency of successful deployments to production
(hourly, daily, weekly, monthly, or yearly).
This measures how often you are delivering value to end users. A higher deployment
frequency means you are able to get feedback and iterate faster to deliver
improvements and features. GitLab measures this as the number of deployments to a
[production environment](../../ci/environments/index.md#deployment-tier-of-environments) in
the given time period.
GitLab displays deployment frequency in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](value_stream_analytics.md).
- **Lead Time for Changes:** The time it takes for a commit to get into production. GitLab
measures this as the median duration between merge request merge and deployment to a
[production environment](../../ci/environments/index.md#deployment-tier-of-environments) for
all MRs deployed in the given time period. This measure under estimates lead time because
merge time is always later than commit time. The
[standard definition](https://github.com/GoogleCloudPlatform/fourkeys/blob/main/METRICS.md#lead-time-for-changes) uses median commit time.
[An issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/328459) to start
measuring from "issue first commit" as a better proxy, although still imperfect.
- **Stability**
- **Change Failure Rate:** The percentage of deployments causing a failure in production.
GitLab measures this as the number of [incidents](../../operations/incident_management/incidents.md)
divided by the number of deployments to a
[production environment](../../ci/environments/index.md#deployment-tier-of-environments) 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 (meaning any incident is
related to only one production deployment, and any production deployment is related to no
more than one incident).
- **Time to Restore Service:** 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](../../operations/incident_management/incidents.md) in the given time period.
This assumes:
- All incidents are related to a [production environment](../../ci/environments/index.md#deployment-tier-of-environments).
- Incidents and deployments have a strictly one-to-one relationship (meaning any incident is related to only one production deployment, and any production deployment is related to no more than one incident).
