Most engineering leaders can tell you their sprint velocity. Far fewer can tell you how often their squads are actually committing code, and what that pattern reveals about delivery health. Commit frequency measures how often players on your team push code changes to a repository over a given time period. It matters because low or erratic commit frequency is often an early signal of blocked work, oversized tasks, or delivery risk building up before it appears in your sprint metrics. This page covers the definition, how to measure it, published benchmarks, how to improve it, and how DevStats surfaces it from your existing Git data.
Key takeaways
- Commit frequency measures how often code changes are pushed to a repository over a defined time window. It matters because consistent, frequent commits are a strong signal that work is being broken down well and that code is moving through the pipeline without long gaps that accumulate risk.
- The formula is simple: Commit Frequency = Total Commits / Time Period (day, week, or sprint). Elite engineering teams, as defined by the DORA State of DevOps 2023 report, tend to commit multiple times per day per player, while low-performing teams may go days between commits on active work streams.
- The most common mistake teams make is treating commit frequency as a productivity score. A player who commits ten times a day is not automatically more effective than one who commits twice. Context matters: task complexity, codebase structure, and review processes all shape what a healthy pattern looks like for your squad.
- DevStats tracks commit frequency automatically by connecting to your Git provider, with benchmarks drawn from 1,000+ engineering teams. Start a free trial to see your squad's numbers in under two minutes.
Commit frequency definition
Commit frequency is the number of code commits pushed to a version control repository within a specific time period. It is a process-level signal that shows how continuously code is flowing through your delivery pipeline, not a measure of individual output.
Technically: Commit Frequency = Total Commits / Time Period. Most teams measure this per day or per week, either at the repository level or rolled up across a squad. When commit frequency drops sharply on an active project, it often points to a process issue: work items that are too large, review bottlenecks, or unclear task scope. Teams that ship reliably tend to show steady, predictable commit patterns rather than bursts followed by long silences. Tracking this metric at the squad level connects directly to delivery predictability, which is what your stakeholders and product partners care about.
Commit frequency sits within the Activity dimension of the SPACE framework and feeds directly into throughput signals that tell you whether your pipeline is moving at a sustainable pace.
Why commit frequency matters for engineering teams
When squads go days without commits on active work streams, the root cause rarely surfaces until a sprint review. Work piles up in long-running branches, merge conflicts multiply, and integration risk grows silently. By the time a sprint misses its target, the signal was already visible in commit patterns days earlier. Squads that commit small, frequent changes reduce integration overhead, catch issues earlier in review, and keep PR cycle time short because there is simply less code to review per pull request.
For engineering leaders, commit frequency connects to two KPIs that matter upstream: on-time delivery and team capacity visibility. Erratic commit patterns can mask whether a squad is genuinely productive or stuck on a blocker that nobody has escalated. It also connects to developer experience: players who are blocked tend to show it in their commit patterns before they say anything in standup. Monitoring the process, not the person, gives you the data to ask the right questions.
In the DORA and SPACE frameworks, commit frequency is a leading indicator for deployment frequency and change lead time. Measuring it is the first step. What you do with that signal is where your judgment as an engineering leader matters most.
How to measure commit frequency
Pull commit data directly from your Git provider: GitHub, GitLab, Bitbucket, or Azure DevOps all expose this via API or native analytics. Calculate total commits per repository per time period, then normalize by squad size if you want a per-player view. For most teams, a weekly cadence is the right measurement window during active sprints. Daily measurement is useful during high-stakes release cycles when you need earlier signals.
No single published benchmark from DORA covers commit frequency at the individual or squad level directly. DORA's State of DevOps research focuses on deployment frequency as the output metric. The table below reflects qualitative patterns observed across engineering teams, and benchmarks will vary by team size, codebase maturity, and release model. DevStats benchmarks let you compare your squad's patterns against teams of similar size and stage.
| Performance level | Commit frequency benchmark | What it signals |
|---|---|---|
| Elite | Multiple commits per day per active player | Work is well-scoped, flow is continuous, integration risk is low |
| High | Daily commits per active player | Healthy delivery rhythm with occasional batching |
| Medium | 2–4 commits per player per week | Some batching or task sizing issues; worth investigating |
| Low | Fewer than 1 commit per player per week on active work | Likely blocked work, oversized tasks, or unclear scope |
These ranges are qualitative guides, not hard thresholds. A squad working on a large refactor may commit less frequently than one shipping features. Context from your sprint data and issue tracker is essential for interpretation.
Commit frequency in practice: a real example
A VP of Engineering at a 45-person SaaS company noticed that one squad was consistently missing sprint commitments despite reporting no blockers in standups. She pulled commit data for the previous four weeks and saw a clear pattern: commits were clustered in the final two days of each sprint, with almost no activity in the first half. The work was getting done, but it was being batched into large, last-minute pushes that left no time for meaningful code review or QA.
She ran a working session with the squad lead to break down the sprint backlog into smaller, independently committable tasks. She also set a squad norm: no pull request should represent more than one day of work. Four sprints later, commit activity had spread across the full sprint window, code review turnaround dropped, and the squad shipped on time in three of the next four sprints. The commit frequency data did not solve the problem. It gave her the signal she needed to ask the right question.
How to improve commit frequency
- Break work items into tasks completable in half a day or less. Large tickets are the most common cause of low commit frequency. If a player cannot complete a meaningful unit of work in a few hours, the task is probably too big. Review your backlog sizing at sprint planning and enforce a maximum story point threshold that your squad agrees on.
- Adopt trunk-based development or short-lived feature branches. Long-running branches discourage frequent commits because players feel they need a "complete" chunk before pushing. Trunk-based development or a branch-per-day discipline creates a natural forcing function for smaller, more frequent commits.
- Monitor PR cycle time alongside commit frequency. If commit frequency rises but PR cycle time stays high, the bottleneck has moved to review. These two metrics work together: one tells you how fast code is being written, the other tells you how fast it is being reviewed and merged.
- Use your activity heatmap to spot patterns, not outliers. DevStats surfaces an activity heatmap that shows commit distribution across the week and sprint. Use it to identify whether your squad's delivery is front-loaded, back-loaded, or consistent, then decide whether that pattern fits your release model.
- Align commit norms with your sprint cadence. If your squad runs two-week sprints, a player should have visible commit activity by day three. Set that expectation explicitly in your team working agreement so it becomes a process standard, not a performance judgment.
Commit frequency vs. deployment frequency
Commit frequency and deployment frequency are related but measure different stages of the delivery pipeline. Commit frequency measures how often code is written and pushed to version control. Deployment frequency, one of the four core DORA metrics, measures how often that code reaches production.
| Commit frequency | Deployment frequency | |
|---|---|---|
| Measures | Code pushed to a repository | Code shipped to production |
| Starts when | A player pushes a commit | A deployment pipeline is triggered |
| Ends when | The commit lands in the repository | The release reaches a production environment |
| Best for | Diagnosing flow issues early in the pipeline | Measuring end-to-end delivery output |
Use commit frequency to diagnose upstream flow problems, and use deployment frequency to measure whether those improvements are reaching production.