Feature Requests

Currently, the New Slack Integration only sends a notification on the following workflow statuses : * Failure * Unauthorized * Error This feature request is to support additional statuses such as Success and Cancelled.

Summary Add build duration (elapsed time) as a data field in CircleCI Slack notifications. Current behavior Slack notifications currently include the commit ID and link, but do not include how long the build took to complete. Desired behavior Include the build duration in Slack notifications, formatted as human-readable elapsed time (e.g., "2 min 34 sec"). Why this matters Build time is a critical signal for engineering teams — it helps identify regressions in CI performance, gives developers an at-a-glance sense of pipeline health, and reduces the need to click through to the CircleCI UI for routine checks. Currently, this functionality is not supported in the new CircleCI Slack integration at all. Users who need build time in notifications must instead fall back to the CircleCI Slack Orb and implement complex workarounds in their config: manually capturing a start timestamp, computing elapsed time via shell arithmetic, and injecting it into a custom Slack orb notification. This adds significant boilerplate across every repo and is brittle to maintain. Proposed implementation Expose build/workflow duration as an available variable or field in Slack notification payloads, so it can be included natively without custom config. Ideally, this would work for both success and failure notifications. User impact Build duration is a commonly requested data point for teams that rely on Slack notifications to monitor CI pipeline health without having to navigate to the CircleCI UI.

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.

Currently no notification is sent to notify of a Scheduled Pipeline failing to trigger. A notification or email should be sent to notify the user/admin that this has occurred so that it can be addressed.

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.

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.

As part of the new CircleCI Slack integration, users need the ability to route different types of notifications from the same project to different Slack channels — for example, sending build notifications to one channel and chunk notifications to another. Problem Statement: The new Slack integration currently supports a single Slack channel per project for notifications. This creates friction in two distinct scenarios: Notification type separation — Teams want different notification categories (builds, chunks, etc.) to go to different channels for better signal-to-noise management. Cross-team pipeline ownership — When Team A owns a pipeline definition but Team B's work triggers failures in it, Team B currently has no way to route those failure notifications to their own channel. The only workaround is to make the pipeline never fail and post to Slack manually — which completely defeats the purpose of automated notifications. Proposed Solution: Within the new Slack integration, allow users to configure multiple Slack channel destinations per project, with the ability to filter/route by notification type (build, chunk, failure, success, etc.) and/or by pipeline definition. User Stories: As a platform engineer, I want build notifications and chunk notifications to go to separate channels so each team stays focused on relevant alerts. As a downstream team, I want pipeline failure notifications routed to my channel even when I don't own the pipeline definition, so I can act on failures that affect my work without relying on the pipeline-owning team.

Extending https://circleci.com/docs/2.0/workflows/#using-contexts-and-filtering-in-your-workflows to also support enabling or disabling certain workflows by commit messages would be EXTREMELY useful! CCI-I-581

When a CircleCI workflow kicks off async work — an external service, another pipeline, or any long-running process — there's no native way to get results back into the workflow and act on them. The only signal a workflow can receive today is a binary approve/reject on a hold job, with no data attached. This means you can't pass results back in, you can't make decisions based on what happened, and if you poll for a response you're burning credits on idle compute. Examples of where this comes up: security scans where you need to route based on severity rather than just pass/fail, ML model training that returns governance metrics and artifact locations, infrastructure provisioning where you need status before proceeding, and pipelines triggering other pipelines where context needs to carry back. Customers today work around this by building callback Lambdas, persisting results to external stores, and writing retrieval logic in downstream jobs — custom glue infrastructure that shouldn't be necessary. We'd love to hear from you on your use cases where you ran into this challenge: What async work are your pipelines waiting on? How are you getting results back into your workflow today? What decisions do your pipelines need to make based on those results? What workarounds have you had to build?