Metric Definition
Commits per developer per day
Track from
Commit frequency
Commit frequency is the average number of code commits a team or individual developer pushes to version control over a defined period, such as commits per developer per day. It is a flow signal that shows how steadily work is moving through the development process. On its own it is not a measure of quality or output, which is why it works best when read alongside the metrics that explain it.
7 min read
What is commit frequency?
Commit frequency is the average number of code commits a team or individual developer pushes to version control over a defined period. If five developers push 100 commits across a 10 day window, commit frequency is 2 commits per developer per day. It is a measure of how often work is being recorded into the codebase, not how much value each commit carries.
Commit frequency matters because it is a leading indicator of flow. Steady, regular commits usually mean small batches of work moving through review and integration without friction. Long gaps followed by large dumps of code often mean work is queuing up somewhere, whether that is a slow review process, unclear requirements, or a single large task that has not been broken down.
The metric is easy to game and easy to misread, so it should never be treated as a productivity score. A developer who commits 20 trivial changes is not more productive than one who commits 3 considered ones. Read commit frequency as a rhythm signal that prompts a question, then look at cycle time, review latency, and deployment frequency to understand what the rhythm is telling you.
Commit frequency is a flow metric, not a performance metric. Never use it to rank or compare individual developers. Use it to spot where work is batching up or stalling, then investigate the cause through review and integration metrics.
How to calculate commit frequency
The core calculation divides total commits by the number of active developers and the number of days in the window. Normalising by developers and days makes the number comparable across teams of different sizes and across periods of different lengths. The inputs below define what counts and over what window.
- 1
Total commits
Count the commits recorded in the period. Decide upfront whether you measure commits to feature branches, commits merged to the main branch, or both, and apply the rule consistently. Squash-merge workflows collapse many small commits into one, so the branch should be measured if you want to see real working rhythm.
- 2
Number of developers
Count only active contributors in the period, not the full headcount. Including engineers on leave or working on non-code tasks understates the true frequency and makes the metric drift for reasons unrelated to flow.
- 3
Number of days
Use working days rather than calendar days so weekends and holidays do not depress the average. A team that commits steadily Monday to Friday should not look slower simply because the window includes a bank holiday.
- 4
Measurement window
Pick a window long enough to smooth out daily noise, such as a sprint or a rolling two week period. A single day is too noisy to be useful because a code freeze or a planning day will swing it sharply.
A worked example. Over a two week sprint with 10 working days, a team of 4 active developers records 120 commits to feature branches. Commit frequency is 120 divided by 4, divided by 10, which equals 3 commits per developer per day. If the next sprint the same team records 60 commits with the same headcount and window, frequency halves to 1.5, which is the signal to ask what changed.
Commit frequency in a metric tree
A single commit frequency number does not tell you why the rhythm changed. A metric tree decomposes it into the causes that actually move it, so a drop becomes a route to a specific bottleneck rather than a vague concern. Commit frequency sits below smaller batch sizes, faster reviews, and fewer blockers, and each of those branches has an owner who can act.
The gap between dashboards and decisions is sharpest with flow metrics like this one. A dashboard tells you commit frequency fell 40 percent last sprint. It does not tell you that the cause was review latency tripling because two senior reviewers were on leave. The tree makes that chain visible.
Metric tree insight
In KPI Tree, each branch carries RACI ownership, so review latency is owned by the engineering lead and requirements clarity is owned by the product owner. When commit frequency moves, the platform pushes the change to the accountable owner of the branch driving it, rather than leaving the whole team to guess at the cause.
Commit frequency benchmarks
There is no universal target for commit frequency because it depends heavily on workflow, language, and how the team defines a commit. The ranges below are directional and assume commits to feature branches in a trunk-aligned or short-lived branch workflow. Treat them as a starting point for conversation, not a scoreboard.
| Pattern | Commits per dev per day | What it usually means |
|---|---|---|
| Low | Under 0.5 | Large batches, slow reviews, or work stalling before integration |
| Healthy | 1 to 3 | Small batches moving steadily through review and CI |
| High | 3 to 6 | Very small commits, common with trunk-based development and feature flags |
| Very high | Over 6 | Often noise from work-in-progress commits rather than a flow signal |
The direction of travel matters more than the absolute number. A team holding a steady 2 commits per developer per day is healthier than one swinging between 0.3 and 5, because consistency points to a predictable process. Always pair the benchmark with deployment frequency and review latency before drawing any conclusion.
How to improve commit frequency
Improving commit frequency means improving flow, not pushing developers to type more. The aim is to remove the friction that makes work batch up, so commits become smaller and more regular as a natural result. The levers below target the most common causes.
Break work into smaller tasks
Smaller, well-scoped tasks produce smaller commits that are easier to review and integrate. Splitting a large story into thin vertical slices does more for commit frequency than any policy about how often to commit.
Cut review latency
A pull request that waits a day to be reviewed blocks the next commit. Setting a review response expectation and limiting work in progress keeps the pipeline moving and prevents commits from queuing.
Speed up the CI pipeline
When tests take 30 minutes, developers batch changes to avoid waiting. A fast, reliable pipeline removes that incentive, so they commit and push as soon as a slice is done.
Surface blockers early
Unclear requirements and cross-team dependencies are the quiet killers of flow. Making blockers visible in standups and tracking how long they stay open stops work from silently stalling before it reaches a commit.
Common mistakes when tracking commit frequency
- 1
Treating it as a productivity score
Ranking developers by commit count rewards small, meaningless commits and punishes deep work. The moment commit frequency becomes a target, it stops being a useful signal.
- 2
Ignoring squash merges
Measuring only commits to the main branch in a squash-merge workflow hides the real working rhythm, because dozens of feature-branch commits collapse into one. Measure the branch if you want to see flow.
- 3
Using calendar days
Dividing by calendar days instead of working days makes any window that includes a holiday look slower, which produces false alarms unrelated to how the team is actually working.
- 4
Reading it in isolation
Commit frequency only becomes meaningful next to review latency, cycle time, and deployment frequency. On its own it raises a question it cannot answer.
Related metrics
Cycle time
Process speed
Operations Metrics
Metric Definition
Cycle Time = Process End Time − Process Start Time
Cycle time measures the total elapsed time from the start to the end of a process. It is a fundamental operations metric used in manufacturing, software development, service delivery, and any context where the speed of a process directly affects throughput, cost, and customer satisfaction.
Deployment frequency
DORA metric
Operations Metrics
Metric Definition
Deployment Frequency = Number of Production Deployments / Time Period
Deployment frequency measures how often an organisation successfully releases code to production. It is one of the four DORA (DevOps Research and Assessment) metrics that predict software delivery performance and organisational outcomes. Teams that deploy more frequently deliver value to users faster, reduce the risk of each individual release, and create tighter feedback loops between development and production.
Sprint velocity
Agile planning metric
Operations MetricsMetric Definition
Sprint Velocity = Sum of Story Points Completed in a Sprint
Sprint velocity measures the amount of work a team completes during a sprint, typically expressed in story points, ideal days, or another unit of estimation. It is a planning tool that helps agile teams forecast how much work they can commit to in future sprints based on their historical completion rate. Velocity is one of the most widely used and most frequently misunderstood metrics in agile software development.
Metric trees for engineering teams
Metric Definition
See where commit frequency sits among the engineering metrics that the team owns and how it rolls up into delivery outcomes.
Input metrics vs output metrics
Metric Definition
Understand why commit frequency is an input metric that you can act on directly rather than an output you can only watch.
Build commit frequency as a metric tree with owners on every branch
See commit frequency decomposed into batch size, review speed, availability, and blockers, with a named owner accountable for each driver. When the rhythm changes, KPI Tree pushes the change to the owner of the branch behind it, so a falling number becomes a clear next action rather than a question for the whole team.
