They can. Deployment frequency counts deployments, and an automated dependency bump that ships is still a deployment. That is not cheating, since small frequent changes are healthy, but the number then reflects maintenance as well as feature work. Report both, or tag deployments by type.
What the metric counts
DORA defines deployment frequency as the number of deployments over a given period or the time between deployments. It says nothing about what the deployment contains. A one line library bump and a new feature each count once.
Why it matters for reading the number
Suppose a service moves from 5 to 15 deployments a month after you switch on automated update pull requests. Feature output has not tripled. The new deployments are small maintenance changes. That is fine and probably good for security, but the headline could suggest a delivery speedup that did not happen for customers.
Tag by type
| Deployment type | Example |
|---|---|
| Feature | New user-visible behavior |
| Fix | Defect repair |
| Dependency | Library or base image update |
| Config | Settings or infrastructure change |
Ask the pipeline to label each deployment from the pull request label, or from a commit convention. Then chart frequency in total and by type.
What to do with dependency deployments
- Keep them in the total. They are real deployments with real risk.
- Chart them separately so feature cadence is visible.
- Track the share that pass automated tests unattended. A high share suggests your tests are doing their job.
- Track change fail rate for dependency deployments on their own. DORA's change fail rate is the ratio of deployments that need immediate intervention, and updates that break things show up there.
- Watch dependency update lag, meaning how old your dependencies are, since it measures the thing the updates are for. Our post on dependency update lag as an exposure metric covers it.
Small batches, in context
DORA's capability page on small batches says working in small batches shortens feedback and makes problems easier to triage. Dependency updates are a natural small batch when they are one library at a time. Grouped update pull requests that bump twenty packages are the opposite, and fail in ways that are hard to untangle.
Pitfalls
- A target for deployment frequency will be met by splitting changes artificially. DORA warns against metrics as goals.
- Merging every update without review trades one risk for another. Gate updates with the same checks as other changes.
- Do not exclude dependency deployments to look slower than you are. Show the full picture.
Quick check
Should I exclude bot-authored deployments?
Not from the total. Show them as their own series so both views are available.
Do dependency updates affect lead time too?
Yes. They are often fast, which can pull the median down. Chart the feature median separately.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a known fix becomes a change you can ship, which is the kind of small deployment this post is about.
How Safeguard fits
Safeguard offers autonomous remediation with fix PRs (off by default, every category on Manual), plus dependency scanning and policy gates to check those changes. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics/
- DORA, Working in small batches: https://dora.dev/capabilities/working-in-small-batches/
Last reviewed: 19 October 2026.
