Not every stage in a CI/CD pipeline should flow automatically into the next one. A stage gate is the deliberate checkpoint that decides whether a change is actually allowed to proceed.
What a stage gate actually is
A deployment stage gate is a required condition a change must satisfy before it’s allowed to move from one stage of a pipeline to the next — commonly between test and staging, or staging and production. A gate might require a passing test suite, a specific approval from a designated person or team, a security scan clearing without critical findings, or an automated check that a monitored metric stays healthy for a defined period after deployment. GitHub’s documentation on using environments for deployment describes one common implementation: environment-level protection rules that a deployment must satisfy before proceeding, ranging from required reviewers to wait timers.
What a gate actually buys
A gate’s value is that it makes a specific risk explicit and enforced, rather than relying on someone remembering to check it manually every time. Requiring a passing test suite as a gate means a change genuinely cannot reach production without it, structurally, rather than as an informal expectation that can be skipped under time pressure. This is the same underlying logic behind blue-green and canary deployment safety mechanisms — deliberately introduced friction, in exchange for a guarantee that a specific bad outcome is much harder to reach by accident.
The real cost: friction and pipeline speed
Every gate slows the pipeline down, by design — that’s the whole point, but it’s also a genuine cost. A manual-approval gate specifically introduces a human bottleneck: the pipeline can’t proceed until someone actually reviews and approves it, which is a meaningfully different kind of delay than an automated check that runs in seconds. Overusing gates — requiring manual approval for low-risk changes that don’t actually need human judgment — erodes the velocity benefits of CI/CD without a matching safety benefit, and tends to produce the same kind of habitual, unthinking approval clicking that undermines the value of the gate in the first place, similar to how over-alerting produces alert fatigue.
Choosing where gates actually belong
A reasonable general principle: place gates at transitions where the cost of a mistake is genuinely high and where the specific check actually reduces that risk — the transition into production is the most common and most justified place for one. Lower-stakes transitions, like promoting a change from a development environment into an internal test environment, often don’t need the same friction, since a problem discovered there is cheap to fix and doesn’t affect real users. Reserving manual-approval gates specifically for the highest-stakes transitions, and relying on automated checks (tests, scans, health checks) everywhere else, tends to strike a better balance than requiring the same level of friction at every stage uniformly.
Key takeaway
A deployment stage gate is a required, enforced checkpoint that stops a change from proceeding until it meets a specific condition — turning an informal expectation into something structurally guaranteed. Gates are worth the friction they add at genuinely high-risk transitions, particularly into production, and counterproductive when applied reflexively to low-risk ones, where they slow the pipeline down without meaningfully reducing risk.
This article explains general CI/CD pipeline concepts; specific gate implementations vary by platform. See our disclaimer.