Currently, when a CircleCI workflow with multiple parallel jobs is canceled, the system sends N+1 webhooks (where N is the number of parallel jobs). This creates integration challenges and unnecessary webhook traffic. We propose to optimize this behavior to align with industry standards and improve customer experience.

Current Behavior

When a workflow is canceled, CircleCI immediately sends an initial webhook with stopped_at = created_at (indicating 0ns duration)

Subsequently, one additional webhook is sent for each parallel job that was canceled

Each webhook contains an incrementally updated workflow duration

Example: For a workflow with 3 parallel jobs, 4 webhooks are sent with durations of 0ns → 35.4s → 40.1s → 1m 8s

Requested Feature

Reduce the number of webhooks sent when canceling a workflow with parallel jobs. Send only one webhook when all jobs have been canceled with the final duration

User Impact

This change would:

Simplify integration with CircleCI webhooks

Reduce server-side processing for customers with stateless architectures

Eliminate the need for custom deduplication logic

Align CircleCI's behavior with industry standards (GitHub Actions, GitLab, Buildkite, Azure Pipelines, AWS CodePipeline)

Business Value

Improve developer experience when integrating with CircleCI

Reduce unnecessary webhook traffic and associated costs