---
title: "The value of CI/CD performance gates | Grafana Labs"
description: "Understand what CI/CD performance gates are and how they shift performance testing from a manual activity to an automated enforcement mechanism."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# The value of CI/CD performance gates

When you run k6 manually, performance testing happens only when someone remembers to do it. Tests run on local machines against whatever environment is convenient, results live in terminal output or scattered dashboards, and there’s no mechanism to prevent a slow release from reaching production. Manual testing gives you information. It doesn’t give you enforcement.

A CI/CD performance gate changes this. A performance gate is a k6 test that runs automatically as a pipeline step. It uses [thresholds](/docs/k6/latest/using-k6/thresholds/), the same thresholds you define in your k6 script, to produce a pass or fail result. When all thresholds pass, k6 exits with code `0` and the pipeline continues. When any threshold is breached, k6 exits with a non-zero exit code, and the pipeline treats this as a job failure. The merge or deploy can be blocked.

Performance gates provide the following advantages:

- **Consistent enforcement**: Every deploy is tested against the same performance criteria, regardless of who triggered it or when.
- **Shift-left feedback**: Developers discover performance regressions in their pull request or staging deploy, not after a production incident.
- **Automated decision-making**: The pipeline decides whether performance is acceptable based on thresholds, removing ad-hoc judgment from the deploy process.
- **Regression prevention**: A change that degrades response times or increases error rates is caught before it reaches users.
- **Audit trail**: Every test run is recorded, creating a history of performance across deploys that you can use for trend analysis.

The two technical enablers that make this work are exit codes and environment parameterization. Exit codes let the pipeline act on test results. Environment parameterization lets the same script run in dev, staging, and production without code changes. You’ll work with both throughout this path.

For broader planning guidance (which tests to automate, which environments, and how often), refer to [Automated performance testing](/docs/k6/latest/testing-guides/automated-performance-testing/).

In the next milestone, you verify that your k6 thresholds are ready to function as pipeline gates.