Manual jobs are CI/CD pipeline tasks that require a person to trigger them before they run. Unlike automated jobs that execute immediately when conditions are met, these pause the pipeline until a user approves or starts them. Teams often use them for production deployments, change approvals, or sensitive operations.
How It Works
In GitLab CI/CD, a job becomes manual when it is configured with the appropriate keyword in the pipeline definition file. When the pipeline reaches that stage, it does not execute automatically. Instead, GitLab marks the job as “manual” and waits for a user with sufficient permissions to trigger it from the web interface or API.
Manual jobs can exist in any stage of the pipeline. They often follow automated build, test, and validation steps. For example, after a successful test stage, the pipeline pauses before deploying to production. An engineer reviews the results, confirms readiness, and then clicks “Run” to continue.
Teams can combine this approach with protected environments and role-based access control. Only authorized users can trigger jobs that deploy to sensitive environments. Some pipelines also use manual jobs with approval rules, requiring multiple reviewers before execution.
Why It Matters
Fully automated pipelines increase speed, but not every step should run without oversight. Production releases, database migrations, and infrastructure changes carry operational risk. A pause before execution provides a controlled checkpoint where engineers verify metrics, review logs, or coordinate with stakeholders.
This approach supports governance and compliance requirements. It creates an auditable record of who approved and triggered a change. Organizations balance automation with accountability, reducing the likelihood of accidental or unauthorized deployments.
Key Takeaway
Manual jobs introduce intentional human control into automated pipelines, enabling safer and more governed software delivery.