Circleci Wait for Approval
You set up a circleci wait for approval step by adding an approval job to your workflow. This special job pauses the pipeline run until a team member clicks approve in the web app. Engineering teams use this pause to gate production changes and database updates. Still, broad project roles often let too many people click that button. Once the job resumes, the runner uses wide permissions that lack fine-grained checks. How a circleci wait for approval step works A delivery pipeline runs a set o
Approval Chains & Escalation + CircleCI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a circleci wait for approval step by adding an approval job to your workflow. This special job pauses the pipeline run until a team member clicks approve in the web app. Engineering teams use this pause to gate production changes and database updates. Still, broad project roles often let too many people click that button. Once the job resumes, the runner uses wide permissions that lack fine-grained checks.
How a circleci wait for approval step works
A delivery pipeline runs a set of jobs in a set order. Most jobs spin up a runner, pull code, and run commands. An approval job works in a different way. It does not start a container or run any scripts. Instead, it puts the workflow into a hold state right away.
Downstream jobs that depend on this hold step will not start yet. They wait in a queue until a user takes action. A team member must log in to the web app and view the workflow map. When they click the hold step, the pipeline marks the gate as passed. Then the downstream jobs start and get the stored secrets for that stage.
Setting up role rules for manual holds
By default, anyone with write permissions on the code repo can approve a held job. This works fine for small teams that share all tasks. Larger teams need stricter rules for production releases. You can link these manual holds to specific groups in your identity provider.
Teams also pair restricted contexts with the jobs that run after the hold step. A context holds secret keys and tokens for target systems. When you restrict a context to a security group, only members of that group can trigger the downstream job. This keeps junior builders from pushing code to live servers on their own. You should check these group lists often to keep roles tight.
What pipeline gates solve and what keeps the session active
Manual pipeline gates solve a clear timing problem for release teams. They stop untested code from reaching live systems during peak hours. They also create an audit log of who clicked the button and when. This helps teams pass basic compliance checks for change management.
Approval Chains & Escalation + CircleCI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, a pipeline hold only decides when a job starts. It does not check what the job does once it runs. After the gate opens, the runner loads static keys and talks straight to your database or cloud. If a script has a bad query, the pipeline cannot stop that single command in flight. And when a build fails, engineers often log in to the live server directly to fix it. At that point, the pipeline gate is out of the loop.
Live sessions also risk leaking sensitive fields in build logs or local terminals. Without field masking that rewrites emails, phone numbers, card numbers, or national IDs in results, raw data can spill into logs. Teams need controls that inspect every command and query at runtime, not just a button before a script runs.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How long does a held workflow stay active before it stops?
A workflow on hold will not wait forever. The platform sets a time limit for manual approval steps. If no one clicks approve before that limit expires, the workflow cancels itself and marks the run as failed.
Can we trigger an approval step through the API?
Yes, you can approve a held job using the platform API. You need the unique ID of the held job and a personal API token. Many teams link this API call to chat bots or ticket tools to speed up sign-offs.
Does a waiting job use up build minutes or runner slots?
No, a waiting job does not use any compute credits or runner slots. The hold happens inside the workflow scheduler, not on a virtual machine. You only pay for compute time once a human approves the step and the next job starts.