そた
I would like to request a native **
type: wait
** job (or step) that pauses the workflow for a specified duration without spinning up a full executor (Docker/Machine). This job should be free or consume significantly fewer credits than a standard container running a
sleep
command.
### Description
Currently, if we need to pause a workflow for a specific amount of time, we are forced to spin up an executor (e.g.,
docker
or
machine
) and run a shell command like
run: sleep 300
.
The Problem:
  1. Wasted Credits:
    We are paying for CPU and RAM resources (e.g., a Medium Docker container) just to count down a timer. This is inefficient for both the user and CircleCI's infrastructure.
  2. Blocked Concurrency:
    These "sleeping" jobs occupy a concurrency slot. On plans with limited parallelism, a sleeping job blocks other important jobs from running.
The Solution:
Please introduce a
Serverless / Executor-less Wait Job
, similar to how
type: approval
works. It should not require a container image and should simply hold the workflow state for
X
seconds/minutes.
Proposed Configuration (Example):
```yaml
jobs:
wait-for-propagation:
type: wait # New native job type
duration: 5m # Duration parameter
workflows:
deploy-and-verify:
jobs:
- deploy
- wait-for-propagation:
requires:
- deploy
- e2e-test:
requires:
- wait-for-propagation
```
### Use Cases (Why is this necessary?)
1. Waiting for Infrastructure Propagation
After a deployment job, we often need to wait for external systems to stabilize before running smoke tests or E2E tests.
*
DNS Propagation:
Waiting for new subdomains to resolve globally.
*
CDN Cache Invalidation:
Waiting for CloudFront/Fastly changes to propagate.
*
Target Group Health Checks:
Waiting for a newly deployed ECS service or Kubernetes pod to pass load balancer health checks.
2. Asynchronous External Processes
Triggering an external job (e.g., a database migration on RDS or a data pipeline) that returns immediately but takes time to complete. We need a "buffer time" before the next job attempts to verify the data.
3. API Rate Limit Throttling
Intentionally slowing down a workflow loop or parallel execution to avoid hitting rate limits of third-party APIs involved in the pipeline.
### Conclusion
By implementing a native
wait
feature, CircleCI would allow users to optimize their pipelines and costs, while also freeing up compute resources on CircleCI's end that are currently being wasted on idle containers.