Feature Requests

We're actively improving CircleCI Outbound Webhooks and want to hear from you! Share your feedback, feature requests, pain points, or use cases below. What would make Webhooks work better for your workflows?

Problem: When jobs fail in CircleCI, there's no way to leave contextual notes explaining why it happened or linking to relevant resources. This leads to repeated investigations, lost knowledge, and wasted time searching for context. Proposed Solution: Add manual annotations on graphs and job timelines (similar to Datadog's annotations) that allow users to: * Pin notes to specific job failures * Add explanations and links (e.g., to Datadog graphs, PRs, tickets) * Make context visible to all team members Use Case: Team has a non-blocking job integration-tests still in development. When it fails, they want to annotate: "Failed due to API rate limiting. See [DD graph]. Will be fixed in Q1. Safe to ignore." This prevents others from re-investigating the same issue and creates a historical record of patterns. Benefits: * Reduced investigation time * Better knowledge sharing across the team * Historical visibility of recurring issues * Improved incident response

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: 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. 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.

Hi folks! Feel free to vote on/comment on this if it resonates with you. Would appreciate if you could elaborate on why your team needs an increased parameter size limit.

For CI optimization at the step level it is difficult to see metric trends. If a job's metrics change then a manual, step level investigation needs to be done on many job instances to make an assumption of the root cause. This trial and error optimization could be mitigated with access to data on the step level.

Support for improved security posture and opportunities to more securely automate API interactions that require highly privileged creds (i.e. publish orbs, policy sets). Additionally, job-based API keys to improve security. Currently v2 automation requires long-lived service account credentials that need to be rotated.

IaC support for GH App pipeline definitions would be great, in additions to the existing API or manual management.

Specifically, a native capability to call a pipeline in another project and wait for a response in the upstream project without custom orchestration steps, workarounds with approval jobs, and/or consuming credits

Optimize costly pipelines with smarter build triggers. The path-filtering-orb is error prone and fragile. Would introduce some degree of parity with Gitlab's downstream pipelines and would be useful in ML training workloads.

We don't display jobs in the order they're defined in config.yml, nor do we sort those jobs in alphabetical order. Jobs are defined in config.yml using an ordered list, so this ordering should be preserved. CCI-I-7