Explain why an approved GitLab deployment may still be waiting to run

Approval satisfies the release gate; the deployment job still requires a separate start.

Source facts

GitLab deployment approvals block jobs targeting protected environments until the required approvals are granted. The deployment job does not have to be configured as a manual job for the approval gate to apply. After approval, however, the documentation requires an operator to run the job manually; approval alone does not start it. A person can provide only one approval per deployment even when they belong to several approver groups. By default, the user who triggered the pipeline cannot approve that deployment.

Source: GitLab — Deployment approvals.

Applicability

This concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.

DSE recommendation

DSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment. Present a release record that identifies the pipeline, commit, environment, required approvals, and final execution step. Avoid repeatedly creating pipelines when the existing job is simply waiting for its authorized start. Review overlapping approver-group membership so the requested approval count can actually be satisfied. Keep self-approval settings deliberate, and revisit approval rules promptly when staff move or their access changes.

Verification

In a test protected environment, observe the blocked job before approval and its state after approval. Confirm that it runs only after the intended operator starts it. Use overlapping test group memberships to verify the one-approval-per-person behavior and record the resulting approval history.

Official reference

GitLab — Deployment approvals. Reviewed October 15, 2026.