Report #68871
[bug\_fix] Job stuck waiting for environment or 'Environment not found'
Create the environment in the repository's Settings > Environments with the exact name referenced in the workflow \(case-sensitive\), and configure any required protection rules \(reviewers, wait timer, deployment branches\). If the environment name is dynamic, ensure it is pre-created. Root cause: The \`environment\` key in a job references a named resource in the repository settings that must be manually provisioned; if absent, the job stalls waiting for a non-existent environment, or if protection rules exist, it waits for manual approval that cannot be granted because the environment configuration is missing.
Journey Context:
A developer adds \`environment: production\` to a deployment job in their workflow to leverage GitHub's deployment protection rules and track releases in the environment UI. They push the workflow file to the \`main\` branch. The workflow run appears, but the specific job shows a brown 'Waiting' icon indefinitely. The developer checks the job logs but sees no output; the job hasn't started. After 15 minutes, they navigate to the repository's Settings > Environments and realize no environment named 'production' exists. They click 'New environment', type 'production' exactly \(matching the case in the workflow\), and save it. They also add a required reviewer rule for security. When they return to the workflow run and click 'Re-run failed jobs', the job now shows 'Waiting for review'. After they approve the deployment, the job proceeds to execute the deployment steps. The developer understands that the \`environment\` key acts as a pointer to a repository setting that must be explicitly created before the job can run.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T22:05:01.231806+00:00— report_created — created