What is deployment frequency, and how do you measure it in Metabase?
Deployment frequency is how often a team successfully releases to production. It's one of the four DORA metrics and the clearest signal of delivery throughput — elite teams deploy on demand, many times a day. Measure it in Metabase from GitHub or GitLab deploy data synced into a database.
TL;DR — Count successful production deployments over time. A merged PR/MR is not a deployment — anchor to real releases (GitHub
Deployments/Actions, GitLab environments/pipelines, or your CD tool).
What does a deployment frequency chart look like in Metabase?
Chart successful production deployments per week as bars, and read the shape rather than any single week. The overall climb is the metric moving the right way — smaller, safer batches — while a one-week dip like Jun 8's usually has a boring explanation, a release freeze or a holiday, worth a note rather than an alarm.
What deployment frequency measures
It counts production releases per day/week, not commits or merges. High, steady frequency usually means small batch sizes and low-risk changes — which correlates with the stability metrics (change failure rate and MTTR) staying healthy.
- Restrict to
environment = 'production'. -
Count only successful deploys (
status = 'success') — failed/rolled-back attempts aren't releases. - Segment by service/repo so a busy monolith doesn't mask quiet services.
What data does it need?
-
A
deploymentstable:environment,status,created_at, andrepository_id/project_id. - GitHub: the Deployments API or Actions deploy workflows. GitLab: environments/deployments from CI/CD pipelines.
SQL patterns
Deployments per week (by service) PostgreSQL
SELECT
date_trunc('week', created_at) AS week,
COUNT(*) AS deployments,
COUNT(DISTINCT repository_id) AS services_deployed
FROM deployments
WHERE environment = 'production'
AND status = 'success'
GROUP BY 1
ORDER BY 1; Average deploys per day (trailing 28 days) PostgreSQL
SELECT
AVG(daily.deploys) AS avg_deploys_per_day
FROM (
SELECT date_trunc('day', created_at) AS day, COUNT(*) AS deploys
FROM deployments
WHERE environment = 'production' AND status = 'success'
AND created_at >= CURRENT_DATE - INTERVAL '28 days'
GROUP BY 1
) daily;Pitfalls
Counting merges as deploys. →
A merge to
main is not a production release; join to real deploys.
Including failed deploys. →
Count only successful production deployments.
Mixing environments. →
Staging and preview deploys inflate the number — filter to production.
One number for all services. →
Segment by repo/service; aggregates hide quiet ones.
Where this metric applies
- GitHub + Metabase — Deployments API or Actions deploy workflows
- GitLab + Metabase — environments and deployment records from pipelines
Related
Metrics
Integrations
Dashboards
Terms
FAQ
How do you calculate deployment frequency?
Count successful production deployments per unit of time: filter to
environment = 'production' and status = 'success', then group by day or week. A merged PR or a green CI run is not a deployment — anchor to real release events from GitHub Deployments/Actions or GitLab environments. Segment by service or repo so a busy monolith doesn't mask quiet services. The SQL patterns above show a weekly count and a trailing 28-day per-day average.Is deployment frequency the same as release frequency?
Effectively yes for DORA — it measures how often code reaches production, whatever your process calls it. If you batch many merges into one release train, count the release; if every merge auto-deploys, count each deploy. What matters is a consistent definition anchored to production, so the trend stays comparable over time and readable next to the other DORA metrics, especially lead time for changes and change failure rate.
Per day or per week?
Report both: a weekly trend for stability and a trailing per-day average (28 days works well) to place yourself in a DORA band — elite teams deploy on demand, multiple times a day. Weekly counts smooth out release trains and holidays; the per-day average gives one comparable number. Segment either view by service, and read it alongside change failure rate so speed never gets reported without stability. See the DORA overview for the bands.
We deploy continuously — what do we count?
Count successful production deploy events, exactly as your CD pipeline records them. With true continuous deployment, frequency tracks closely with merges to the release branch, so the number stays high and steady — at that point the more interesting metrics are lead time for changes (is the pipeline itself fast?) and change failure rate (are the frequent deploys safe?). Deploy records come from GitHub Actions/Deployments or GitLab pipelines.
How do you track deployment frequency in Metabase?
Sync deploy records from GitHub or GitLab into a SQL database, model a
deployments table with environment, status, timestamp, and repository, and define the count once as a saved question grouped by week. Put it on a software delivery dashboard next to the other DORA metrics so throughput and stability are always read together.