GitLab · CI/CD jobs · Checked October 28, 2026

GitLab: "You are not authorized to run this manual job"

GitLab shows this message, with Run disabled, when you try to run a manual job and either the job deploys to a protected environment whose Allowed to deploy list does not include your account, or the project prevents outdated deployment jobs and running this one would overwrite the latest deployment (GitLab: job troubleshooting, checked October 28, 2026). A protected branch can stop you too; see why GitLab refused a pipeline or a job.

You are not authorized to run this manual job

A protected environment

• Who may deploy: a protected environment lets only the people with the right privileges deploy to it; GitLab administrators can use all environments. Protected environments are in GitLab Premium and Ultimate (protected environments).
• Where it is set: in the project, Settings > CI/CD, expand Protected environments (at least the Maintainer role). The Allowed to deploy list takes a role (Maintainers, or Developers, which means Maintainer and Developer), groups invited to the project, or users with the Developer, Maintainer or Owner role.
• The Reporter role: a Reporter can be allowed only through a group invited to the project with the Reporter role. That is deployment-only access: they may deploy even without push or merge access to the branch.
• Group settings: a group can protect environments by their deployment tier, such as production. If both the project and the group protect it, you must be allowed in both.
• A trigger job: a job with trigger but without the environment keyword is not tied to the protected environment, so deployment-only access does not apply to it. Add environment to the trigger job.
• A job that is not manual: when it is about to start for a user who may not deploy there, GitLab fails it as protected_environment_failure: "The environment this job is deploying to is protected. Only users with permission may successfully run this job." (GitLab source: ee/app/services/ee/ci/process_build_service.rb and app/presenters/commit_status_presenter.rb, read on October 28, 2026).

Prevent outdated deployment jobs

• The setting: in the project, Settings > CI/CD, expand General pipelines, Prevent outdated deployment jobs. It keeps an older deployment job from finishing after a newer one and overwriting the newer deployment (deployment safety).
• A manual job: if it is older than the latest deployment, GitLab disables Run and says that the job must be started manually but is older than the latest deployment, so it cannot run.
• A job that starts: it fails as failed_outdated_deployment_job, shown as failed outdated deployment job in the pipeline and as "The deployment job is older than the latest deployment, and therefore failed." on the job.
• Age: GitLab compares the start time of the jobs, not the commit time. If pipeline A (older commit) and pipeline B (newer commit) both have manual deployment jobs, and you start the job of A after B was created, the job of B is blocked as outdated.
• Rollback: with Allow job retries for rollback deployments (on by default), you can retry an older deployment job that already ran, to roll back. With it cleared, run a new pipeline on the older commit instead.

What the API answers

• Running the job (POST /projects/:id/jobs/:job_id/play): GitLab checks whether your account may run the job before it checks whether the job can be run, so the answer is 403 Forbidden, not 400 Unplayable Job. Retrying and cancelling the job are refused the same way (GitLab source: lib/api/ci/jobs.rb, app/policies/ci/deployable_policy.rb).
• GraphQL: on a job, playable says the job can be played, and stays true for an account that may not run it; canPlayJob says that the job can be played and that the current user may play it (app/graphql/types/ci/job_type.rb).

What to do

• Protected environment: ask a Maintainer to add your account, your role or a group you are in to Allowed to deploy, or ask someone on that list to run the job.
• Outdated: run the deployment job of the newest pipeline. To deploy older code on purpose, retry its deployment job if rollback retries are allowed, or run a new pipeline on that commit.
• Protected branch: on a protected branch, only users allowed to merge or push to it may run manual jobs (unless a protected environment allows them to deploy); see pipeline or job refused.

GitLab jobs in IntelliJ IDEA

Pipeline Inbox for GitLab CI, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pipelines of your GitLab projects with their jobs by stage, and with Pro retries, cancels and runs them. From version 1.0.21, Run Manual Job is disabled where GitLab says your account may not run the job (canPlayJob), and its description says why: your role, a protected branch or a protected environment, or a job older than the latest deployment. A refusal with 403 names protected environments too. Before, it was offered wherever GitLab said the job could be played, and a 403 named only your role or a protected branch. Reading is free; retrying, cancelling and running are Pro (US$1.50 a month, with a 30-day trial).

GITLAB is a trademark of GitLab Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitLab Inc. or JetBrains.

More: GitLab pipeline or job refused (400, 403, 409, 429) · GitLab "Insufficient permissions to set pipeline variables" · GitLab job dropped as stuck or over its timeout · GitLab job waiting for resource · GitLab job log refused or empty · GitLab "This job does not have a trace." after 18.0 · GitLab "insufficient_scope" · GitLab pipeline plugins for IntelliJ IDEA, compared · 日本語