GitHub Actions · Checked October 30, 2026

GitHub Actions: approving a deployment that is "Waiting" for review

A job that names an environment with Required reviewers stops in the Waiting state until one of the reviewers approves it. On GitHub you approve it from Review deployments on the run's page; the GitHub CLI has no command for it, but gh api can do it. If nobody approves within 30 days, the run does not go on.

What waits, and for how long

Who can approve: up to 6 people or teams listed under the environment's Required reviewers, with at least read access to the repository. One approval is enough for the job to go on (GitHub's documentation, Deployments and environments).
What you see: the run and the job have the status waiting (in the REST API and in gh run list --status waiting); the jobs before it finish as usual.
How long: "A workflow may wait for up to 30 days on environment approvals", and a whole run is limited to 35 days, "time spent on waiting and approval" included (GitHub's Actions limits). We read two public runs on October 30, 2026 that had been waiting for 3 and 24 days.
After the review: approved, the job goes on once any other protection rules pass, and only then can it read the environment's secrets. Rejected, the workflow fails.
Other things that also make a job wait: a Wait timer (1 to 43,200 minutes, not billed), the environment's deployment branches and tags, or a custom protection rule. These do not ask anyone for a review.

Approve on GitHub

Open the workflow run. A run that needs your review shows a notice with Review deployments; click it.
Select the environment or environments, and leave a comment if you like.
Click Approve and deploy, or Reject.

Repository administrators can instead force all waiting jobs of an environment through: Start all waiting jobs next to Deployment protection rules, then I understand the consequences, start deploying. That is refused when the environment has Allow administrators to bypass configured protection rules turned off (GitHub's documentation, Reviewing deployments).

Approve from the command line

There is no gh run command for it: the feature request (cli/cli#5773) has been open since June 2022. The REST API does it in two calls. First the environments the run waits for, with their ids and whether you may approve:

gh run list --status waiting
gh api repos/OWNER/REPO/actions/runs/RUN_ID/pending_deployments \
  --jq '.[] | {name: .environment.name, id: .environment.id, current_user_can_approve}'

Then the review. Send the body as JSON with --input: with -f environment_ids[]=… the id goes as a string and GitHub answers HTTP 422 For 'items', "…" is not an integer. (cli/cli#8166).

echo '{"environment_ids":[ENVIRONMENT_ID],"state":"approved","comment":"Ship it"}' |
  gh api --method POST repos/OWNER/REPO/actions/runs/RUN_ID/pending_deployments --input -

state is approved or rejected, and comment is required. Only required reviewers can send it. A token needs the repo scope (classic) or, fine-grained, Deployments read and write; reading the pending deployments needs Actions read (GitHub's documentation, Review pending deployments for a workflow run).

No Review deployments button

You started the run and the environment has Prevent self-review: then "users who initiate a deployment cannot approve the deployment job, even if they are a required reviewer". Someone else on the list has to approve. In the REST API, current_user_can_approve is false.
You are not on the list, neither yourself nor through a team on it.
The job is not waiting for a review but for a wait timer, a branch rule or a custom rule.
A private repository on GitHub Free, Pro or Team: "required reviewers are only available for public repositories" there; environments themselves work in private repositories on Pro, Team and Enterprise. The Required reviewers option does not appear, or appears once the repository is made public, as a Team plan owner reported in August 2025 (community#170307). On those plans one way round is to start the deploy workflow by hand (workflow_dispatch), which limits who can deploy to those who can start it, rather than asking for a review.

HTTP 422 "At least one environment has already been approved or rejected"

The answer to the review call when the environment is no longer waiting for one, as a public report of October 2026 quotes it:

gh: At least one environment has already been approved or rejected (Validation Failed)

Another reviewer got there first, or the run was cancelled (in that report, by a newer push) while a list still showed it as waiting. Read the run's status again before treating it as a failure: when it is no longer waiting, there is nothing left to approve.

One approval for every job

An environment belongs to a job, not to the workflow. When several jobs name a protected environment, each job that reaches it waits for a review, and people with many such jobs report approving again and again. Naming the environment once for the whole workflow has been requested since April 2022 (community#14417). The ways round are to put the steps that need the environment in fewer jobs, or to approve every environment the run is waiting for in one review.

The notice comes, but not the run

GitHub notifies the reviewers: "<user> requested your review to deploy to an environment" (reason approval_requested). Public reports from October 2026 add that when a team is the reviewer every member gets it, and that the notification's API entry has no subject URL, so inbox tools link to the repository instead of the run. To find what is waiting for you, list the runs with gh run list --status waiting in each repository, or GET /repos/OWNER/REPO/actions/runs?status=waiting.

Approve deployments from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window. Its Waiting for review filter shows the runs that are waiting, across repositories; a run that waits for you says "Waiting for your review to deploy to" and the environment, and Approve or Reject sends the review with a comment for every environment GitHub says you may approve, in one step. When a run waits for a review you may give, anyone's run included, the IDE says so once in a notification (the workflow, run, environment and repository), and Open goes straight to the run with Approve and Reject; GitHub's own notification of the request links to the repository, not the run. The current branch's runs are in the status bar, a waiting one before a running one. Reading is free; re-running, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial). A fine-grained token needs Deployments read and write to review.

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: "Unable to retry this workflow run because it was created over a month ago" · "Workflow does not have 'workflow_dispatch' trigger" · GitHub Actions plugins for IntelliJ IDEA compared · 日本語