Feature Requests

The current native Slack integration enforces a hard 1:1 constraint — one Slack workspace can only be connected to one CircleCI organization at a time. For enterprise customers, this is a significant blocker. Many enterprise organizations authenticate via GitHub and operate across multiple distinct CircleCI organizations to manage separate business units, product teams, or subsidiaries — all while routing into a single corporate Slack workspace. The ask: Allow a single Slack workspace to receive notifications and interact with multiple CircleCI organizations simultaneously.

Currently, there is no mechanism to remove the ability to add environment variables at a project-level. To ensure all secrets live within a context, allow the ability to remove this functionality or restrict its usage

When CircleCI ships a new self-hosted runner version, it currently rolls out automatically with no supported way to stay on, or roll back to, a known-good recent version without infrastructure surgery. In May 2026 a broken release of the Windows self-hosted runner stopped working entirely. The auto-update meant every one of our runners picked it up. We had no clean way to revert. Working around it required an extreme hack to force a previous version onto our machines. The cost was severe: Two full days of engineering effort to diagnose and build the workaround. Half a day of lost productivity for the entire engineering team while CI was down. What we'd like: An easy, supported way to choose a specific recent runner version, including the immediately previous one. Bonus: control it via a CircleCI-side setting rather than runner config. If a bad release ships again, we flip the setting and recover with zero changes to our own infrastructure. A short window where the last few versions remain installable, so rollback is always possible. An announcement channel with a changelog so we are aware of runner changes. Why a setting matters: During an outage, touching infrastructure is the slowest and riskiest path - it needs deploys, approvals, and access to machines that may already be mid-incident. A toggle in the CircleCI UI or API lets us recover in minutes. This would turn a two-day, whole-team incident into a one-click rollback.

We're rolling out a new "Compare" page in your plan settings that lets you visualize and compare your credit consumption across the past few billing cycles. With this page you can: See trends in how your spend has changed over time Compare usage at the plan level or drill down into individual projects Filter by charge type (e.g., compute, users, network) You'll find it as a new tab in your plan settings navigation. This is a beta feature, so we'd love your feedback on what's useful, what's missing, and how we can make it better. Drop your thoughts here!

Add a notification trigger that fires when a build passes for the first time after a failure. Currently users can filter to failed-only notifications, but there's no recovery signal — leaving engineers to manually check CircleCI to know when a pipeline is healthy again. Customer evidence: A beta native Slack integration user specifically requested this as a complement to failed-only filtering — they want the failure-to-recovery loop closed without switching back to "all notifications" mode. Expected outcome: Allow users to opt-in to be notified when a pipeline recovers, reducing manual monitoring toil and completing the failure response workflow entirely within Slack.

Allow users to configure which details are included in native Slack failure notifications. Teams have different signal-to-noise preferences — some want full context, others want lean, scannable alerts. Initial fields to consider toggling on/off: * Commit message * Branch name * Triggered-by user * PR link Customer evidence: A beta user with a high-volume monorepo specifically requested the ability to hide commit messages for better information density. This is a broader pattern — teams migrating from legacy Slack integrations have often already tuned their notifications, and customization parity is a key adoption driver. Expected outcome: Users can tailor notification content to avoid information overload while ensuring the details most relevant to their workflow are always surfaced — leading to notifications that are actually read and acted on, rather than missed, dismissed or muted.

If "Auto-cancel redundant workflows" is enabled, it should also apply to PRs/branches that get merged into master. There's no use finishing a build for a PR that just got merged into master, because it's going to get built there too.

An ask to open source the self hosted runner agents so the community can work with the team on any issues

Currently, only org admins can manage runner resource classes. This blocks the onboarding of new runners onto CircleCI due to the escalated privileges required.

There are a couple different paths for a user to view a soft or hard fail config policy decision associated with their pipeline, some requiring the user to be admin, but the user is alerted only when the pipeline is hard failed. It would be helpful if the decision output was more easily surfaced locally. Hard failures are surfaced via the Pipeline API. Soft failures are only present in the UI for a non-admin user. A slack notification, something on the PR, adding soft failures to the API, etc would be helpful to surface policy decisions to the user.