CircleCI

CircleCI exposes several object types through its API: pipelines, workflows, jobs, and aggregated insights at the project and workflow level. This integration focuses on workflows and pipelines, which represent the fundamental unit of delivery activity and the most direct source of per-developer performance data. Five KPIs were retained, selected against the same three criteria applied across all integrations: ability to attribute to an owner, resistance to gaming, and balance between leading and lagging indicators. Attribution in CircleCI operates through the VCS login of the developer who triggered each pipeline, which requires a mapping step to resolve usernames to email addresses via GitHub or GitLab.

Delivery reliability: reading Deployment Frequency and Change Failure Rate together

Deployment Frequency counts the number of successful workflow runs per developer on the default branch over a given period. Change Failure Rate measures the proportion of those runs that resulted in failure. These two indicators form the first axis of the DORA framework and are deliberately designed to be read in tension with one another. A high Deployment Frequency alone says nothing about the quality of what is being shipped: a developer who triggers ten deploys a week, half of which break the pipeline, is not delivering at twice the pace of one who ships five stable deploys. Conversely, a low Change Failure Rate achieved by shipping rarely is not a sign of quality discipline — it may simply reflect avoidance of risk. The combination of the two indicators distinguishes productive delivery cadence from either rushed instability or excessive caution.

Change Failure Rate also serves as the primary counter-indicator to gaming on Deployment Frequency. Because pipeline triggers are directly under developer control, a developer under pressure to increase their frequency could do so by pushing trivial commits or retrying failed builds. Change Failure Rate neutralizes this behavior: artificial volume inflation without quality improvement will register as a degraded failure rate, making the inflation visible in the data.

Incident response: Mean Time to Recovery as a behavioral signal

Mean Time to Recovery measures the average elapsed time between a failed workflow on the default branch and the next successful run triggered by the same developer. Unlike Change Failure Rate, which measures how often failures occur, Mean Time to Recovery measures what happens after a failure: how quickly the developer detects, diagnoses, and resolves the regression. The two indicators address different behavioral dimensions. A team can have a low failure rate and a poor recovery time — suggesting that when failures do occur they are complex or treated with low urgency. A team with frequent failures but rapid recovery may reflect a high-iteration culture with mature incident response.

Mean Time to Recovery is bounded by the 90-day historical window available through the CircleCI Insights API. Regressions that remain unresolved across reporting periods may appear truncated in the calculation. This limit is structural and should be noted when comparing this KPI across teams with different incident management practices.

Pipeline efficiency and feedback loop speed

Mean Pipeline Duration measures the average execution time of workflow runs attributed to a developer. Time to First Green measures how long it takes, from the first pipeline trigger on a new branch, for that developer to reach a first successful run. These two KPIs are distinct in what they measure and in how they should be interpreted.

Mean Pipeline Duration is primarily a lagging indicator of pipeline architecture quality. A developer whose pipelines consistently run long is not necessarily less productive, but long pipelines impose a slower feedback loop on every iteration: each code change takes longer to validate, which accumulates into a structural drag on delivery frequency. A sustained increase in Mean Pipeline Duration, absent any corresponding increase in test coverage or build complexity, is a signal that the pipeline itself has accumulated technical debt — unnecessary steps, redundant jobs, or unoptimized caching.

Time to First Green operates at a different point in the development cycle. It captures the duration of the validation loop at the start of a new branch: how quickly a developer can confirm that their initial implementation is structurally sound. A short Time to First Green indicates that the developer writes code that integrates cleanly from the first attempt, and that the pipeline provides fast feedback. A long Time to First Green may signal issues with local development environment setup, test configuration, or integration complexity. As the only leading indicator in this integration, Time to First Green anticipates delivery rhythm — a developer who consistently achieves a short first-green time is positioned to iterate faster throughout the rest of the branch lifecycle.

Scope and limits of the integration

CircleCI records pipeline execution outcomes but does not measure the quality of what is being delivered. A successful deployment may ship a feature that functions correctly or one that will generate regressions in production; the pipeline data does not distinguish between the two. Change Failure Rate captures pipeline-level failures — build errors, test failures, infrastructure errors — but does not capture production incidents that emerge after a successful deploy. The gap between pipeline success and production reliability is not visible within CircleCI data alone.

Attribution in this integration relies on the VCS login of the pipeline trigger actor, which must be resolved to a Human Bridge user email via a GitHub or GitLab API mapping. Any pipeline triggered by a bot, a shared service account, or an automated system will not be attributed to an individual developer. The reliability of per-developer KPIs therefore depends on team discipline around pipeline authorship: integrations that run automated deploys under a shared account will systematically undercount individual contribution.