How to Calculate Cycle Time: A DORA Metrics Guide
June 4, 2026•CloudCops
Your team ships every week. Pull requests move. Pipelines stay green often enough. Stakeholders still ask the same uncomfortable question: are we getting faster, or are we just busy?
That's where most platform and engineering leaders get stuck. Velocity doesn't answer it. Story points definitely don't answer it. A release calendar can show activity, but it can't show friction. If you want a delivery metric that exposes where work slows down between “we started building this” and “customers can use it,” cycle time is the one that matters.
In software delivery, measuring cycle time well is less about the subtraction and more about the boundary choices, event mapping, and data hygiene. The formula itself is easy. The implementation is where teams get burned.
Beyond Feeling Fast Why You Need to Measure Cycle Time
A lot of teams operate on vibes. They feel productive because engineers are active, tickets are moving, and releases happen regularly. Then leadership asks for DORA metrics, and the room gets quiet because nobody trusts the data behind the dashboard.
Cycle time fixes that problem when you define it in a way that matches how software ships. It gives you a direct view of flow through your engineering system, not just output at the end of a sprint. In plain terms, the foundational way to calculate cycle time is net production time divided by units produced, written as Cycle Time = NPT ÷ U. A simple example is 420 minutes ÷ 350 units = 1.2 minutes per unit, and another common example is 390 minutes ÷ 96 units = 4.06 minutes per unit according to Wrike's cycle time formula overview.
That manufacturing-style formula matters because it teaches the core idea correctly. Cycle time is about throughput per unit of completed work. In software, the “unit” isn't a factory part. It's usually a change, pull request, or deployable work item. The math stays simple. The hard part is deciding what counts as a unit and when the clock starts.
Why platform teams should care
Platform engineering leaders shouldn't track cycle time just to populate an executive scorecard. They should track it because it surfaces system constraints that engineers already feel but can't prove.
Common examples show up fast:
- Review queues grow because senior engineers approve everything.
- CI waits expand because test suites and shared runners bottleneck under load.
- Deployments bunch up because release windows are still manual even though the repo is fully automated.
- GitOps reconciles slowly because the delivery event isn't being captured from the actual production controller.
Those aren't people problems first. They're flow problems.
Practical rule: If you can't point to the exact stage where elapsed time accumulates, you don't have a cycle-time metric. You have a guess.
What cycle time tells you that other metrics don't
Cycle time answers a brutally practical question: once work begins, how long does it take to reach production? That makes it useful for diagnosing process efficiency inside the delivery path itself.
It also forces cleaner operational thinking. Teams stop debating whether they're “working hard” and start examining whether handoffs, review policies, flaky tests, artifact promotion rules, or deployment gates are creating delay.
For a DORA program, that matters because improvements usually come from system design. Not from asking developers to move faster.
What Exactly Are You Measuring
If you want clean cycle-time data, define the clock edges before you write a single query.
For software delivery, the most useful definition is this: cycle time starts at the first commit associated with a change and ends when that same change is successfully deployed to production. That gives you a consistent path across Git, code review, CI, artifact creation, and deployment.
The reason this definition matters is simple. In knowledge work, the boundary is often fuzzy. Many guides explain cycle time as a simple average, but they don't resolve the harder issue of what counts as the start and end of a cycle. That gap matters because the same task can produce very different numbers depending on the boundary choice, as noted in Monday.com's discussion of cycle time definitions.
If your team wants a broader DORA framing before locking this down, CloudCops has a useful primer on what DORA metrics are.
The definition that holds up in real pipelines
I prefer first commit to production because it maps to real system events. Assignment timestamps are messy. “In progress” states in Jira are often delayed or backfilled. Merge time is too late because it hides development effort. Production success is the only end state that means customer-facing value is live.
That doesn't mean every team must use this exact definition. It means every team must choose one that is unambiguous and mechanically observable.
Use these rules:
- Start with an event the toolchain records automatically. First commit on the branch is usually reliable.
- End with an event that proves delivery happened. Production deployment success, not “approved,” not “merged.”
- Apply the same rule across repos and services. Otherwise comparisons become useless.
Break cycle time into phases
A single total number won't tell you where the delay lives. Split it into sub-phases that map to timestamps you can collect.
| Phase | Start | End | Why it matters |
|---|---|---|---|
| Coding time | First commit | Pull request opened | Shows how long work stays local before review |
| Review time | Pull request opened | Pull request merged | Exposes approval latency and rework loops |
| CI and testing time | Pull request merged | Deployable artifact ready | Shows pipeline throughput after merge |
| Deployment time | Deployment started | Production success | Captures release mechanics and GitOps lag |
This model works because each phase maps to a distinct operational surface.
What doesn't work
Some teams calculate cycle time from ticket creation to deployment. That's usually lead time, not cycle time. Others start the clock at PR open. That produces a cleaner number, but it hides the coding phase completely.
Neither choice is automatically wrong. They're wrong when people compare them as if they mean the same thing.
If two teams use different start events, they are not measuring the same metric, even if the dashboard label says cycle time.
Finding the Truth in Your Toolchain
The timestamps you need are rarely in one place. Git has commit events. GitHub or GitLab has pull request events. CI systems know when builds completed. Your deployment controller knows when production converged. If you only measure one of those systems, you're missing the full path.
The job is to map each conceptual stage to a concrete system event and then decide what ID ties those events together. In modern setups, that's usually a commit SHA, a pull request number, a merge commit, an artifact version, or a GitOps revision.
The event mapping that usually works
Here's the checklist I use when instrumenting cycle-time collection in a GitOps-heavy stack.
| Cycle Time Stage | Start Event | End Event | Primary Data Source(s) | Key Data Point(s) |
|---|---|---|---|---|
| Coding | First code change begins | Pull request created | Git, GitHub, GitLab | first commit timestamp, branch name, author, PR number |
| Review | Pull request opened | Pull request merged | GitHub API, GitLab API | PR created_at, review submitted events, merged_at |
| CI and testing | Merge accepted | Deployable artifact available | GitHub Actions, Jenkins, GitLab CI, artifact registry | workflow completion time, pipeline status, artifact digest or tag |
| Deployment | Production rollout starts | Production deployment succeeds | ArgoCD, FluxCD, deployment events, observability annotations | sync start, sync success, revision, environment, service |
Where teams usually mis-map the data
The biggest mistake is assuming the repo tells the whole story. It doesn't. Git can tell you when work started, but Git can't prove production success. In GitOps, production completion often lives in ArgoCD application history, Flux events, or deployment annotations emitted into your observability stack.
Another common mistake is joining the wrong objects. If you join by ticket ID alone, you'll lose precision when several commits belong to one work item. If you join by branch name, rebases and squash merges can make correlation brittle. The safest path is usually a chain:
- Commit SHA links code to PR
- Merge SHA or image digest links PR to build artifact
- Revision or artifact digest links build to deployment
If your delivery path is inconsistent, fix that before you chase reporting quality. A team following strong CI/CD pipeline practices will have a much easier time measuring cycle time because the handoffs are explicit and auditable.
Tool-specific notes that save time
A few practical details matter more than people expect:
- GitHub and GitLab timestamps are event timestamps, not business-state truth. A merged PR may still be far from production.
- GitHub Actions and Jenkins identify workflow completion, not customer availability. Don't treat a green pipeline as “done.”
- ArgoCD sync success is useful, but only if the app targets production. Separate environments cleanly.
- Observability platforms help when the deployment controller is messy. A release annotation in Grafana, Loki, or OpenTelemetry can become the production truth event if your deployment tool doesn't expose clean history.
The right source of truth is the system that can prove the change is live, not the system where the developer stopped touching it.
From Raw Data to Actionable Metrics
Once the event model is clear, the implementation becomes a data-correlation problem. You're collecting timestamps from multiple systems, normalizing IDs, and turning them into durations that teams can inspect by service, repo, or environment.
In most organizations, there are three workable patterns:
- A warehouse-first model using SQL.
- An observability-first model using Elasticsearch or log aggregation.
- An API-first script that fetches data directly from delivery tools.
The right choice depends on your architecture, not on taste.
SQL for teams with a warehouse
If Git, CI, and deployment events already land in BigQuery, Snowflake, or PostgreSQL, SQL is the cleanest way to calculate cycle time. The important part is to model one row per delivered change.
WITH first_commit AS (
SELECT
pr_number,
MIN(commit_timestamp) AS first_commit_ts
FROM git_commits
GROUP BY pr_number
),
pr_events AS (
SELECT
pr_number,
created_at AS pr_open_ts,
merged_at AS pr_merge_ts,
merge_commit_sha
FROM pull_requests
WHERE merged_at IS NOT NULL
),
artifacts AS (
SELECT
commit_sha,
MIN(completed_at) AS artifact_ready_ts
FROM ci_builds
WHERE status = 'success'
GROUP BY commit_sha
),
prod_deploy AS (
SELECT
revision_sha,
MIN(deployed_at) AS prod_success_ts
FROM deployments
WHERE environment = 'production'
AND status = 'success'
GROUP BY revision_sha
)
SELECT
p.pr_number,
f.first_commit_ts,
p.pr_open_ts,
p.pr_merge_ts,
a.artifact_ready_ts,
d.prod_success_ts,
EXTRACT(EPOCH FROM (p.pr_open_ts - f.first_commit_ts)) AS coding_seconds,
EXTRACT(EPOCH FROM (p.pr_merge_ts - p.pr_open_ts)) AS review_seconds,
EXTRACT(EPOCH FROM (a.artifact_ready_ts - p.pr_merge_ts)) AS ci_seconds,
EXTRACT(EPOCH FROM (d.prod_success_ts - a.artifact_ready_ts)) AS deploy_seconds,
EXTRACT(EPOCH FROM (d.prod_success_ts - f.first_commit_ts)) AS total_cycle_seconds
FROM pr_events p
JOIN first_commit f ON p.pr_number = f.pr_number
LEFT JOIN artifacts a ON p.merge_commit_sha = a.commit_sha
LEFT JOIN prod_deploy d ON p.merge_commit_sha = d.revision_sha
WHERE d.prod_success_ts IS NOT NULL;
This query is intentionally plain. Real implementations usually need to handle squash merges, cherry-picks, multi-service repos, and redeploys. But the shape is right. Build a canonical delivery event model first. Then optimize.
If you also track adjacent flow metrics, it helps to compare cycle time with lead time for changes so you don't confuse active delivery duration with the wider request-to-release path.
Elasticsearch for observability-centric stacks
Some teams don't have a warehouse, but they do have structured logs in Elasticsearch or OpenSearch. That's enough if your systems emit events with consistent fields.
A simplified query pattern looks like this:
POST delivery-events/_search
{
"size": 0,
"query": {
"bool": {
"filter": [
{ "term": { "environment": "production" } },
{ "term": { "status": "success" } }
]
}
},
"aggs": {
"by_change": {
"terms": {
"field": "change_id.keyword",
"size": 1000
},
"aggs": {
"first_commit": { "min": { "field": "first_commit_ts" } },
"pr_open": { "min": { "field": "pr_open_ts" } },
"pr_merge": { "min": { "field": "pr_merge_ts" } },
"artifact_ready": { "min": { "field": "artifact_ready_ts" } },
"prod_success": { "min": { "field": "prod_success_ts" } },
"total_cycle_ms": {
"bucket_script": {
"buckets_path": {
"start": "first_commit",
"end": "prod_success"
},
"script": "params.end - params.start"
}
}
}
}
}
}
This approach only works if you normalize events before they hit the index. Don't expect Elasticsearch to rescue inconsistent event shapes after the fact.
A script when everything is fragmented
Sometimes the practical answer is a script that calls GitHub, Jenkins, and ArgoCD APIs, correlates events, and writes a daily fact table. That's a valid starting point.
The pattern is straightforward:
- fetch merged PRs for a time window
- find the earliest commit attached to each PR
- fetch successful CI results for the merge SHA
- fetch production deployment success for the same revision
- calculate durations and write the output somewhere queryable
For teams that want to analyze trend behavior rather than just static snapshots, PlotStudio AI on time series methods is a good reference for thinking about rolling windows, seasonality, and variance in operational metrics.
A short visual overview helps if you're explaining this pipeline to stakeholders or building a shared measurement model with engineering managers.
One opinionated recommendation
If you're building this from scratch, prefer a daily batch pipeline that produces durable cycle-time facts over live dashboard math stitched directly to APIs. Live joins across GitHub, CI, and deployment systems are fragile. Cached facts are auditable and easier to debug.
CloudCops GmbH is one option for teams that want help wiring GitOps, CI/CD, observability, and DORA-style delivery metrics into the same platform workflow.
Building Dashboards That Tell a Story
A cycle-time dashboard should help an engineering leader answer three questions quickly. What's typical right now. Is the system getting more or less predictable. Where is the delay accumulating.
If your dashboard shows one blended average, it fails all three.
The panels that matter
A useful Grafana or Looker dashboard usually starts with a single summary tile, but not an average. Use the median as the headline number because it reflects the typical experience better when delivery data is uneven.
Then add a time-series panel that tracks multiple slices of the distribution over time. The goal isn't decoration. It's to see stability versus volatility. A flat typical value with growing tail latency tells a very different story from a broad improvement across the whole distribution.
The third panel is the one many teams skip and then regret skipping: a breakdown of total cycle time by stage.
Use a stacked bar chart or stacked area view that shows:
- Coding
- Review
- CI and testing
- Deployment
If review dominates, you likely have a staffing or approval-pattern problem. If CI expands, the bottleneck is usually test design, runner capacity, or pipeline topology. If deployment time widens, look at environment controls, GitOps convergence, rollout checks, or release governance.
What the shapes usually mean
A good dashboard helps you interpret patterns, not just admire charts.
| Dashboard pattern | Likely meaning | What to inspect |
|---|---|---|
| Median stable, upper tail widening | Most work is fine, some items are getting stuck badly | blocked changes, cross-team dependencies, large PRs |
| Review time dominates | Human queue problem | reviewer load, CODEOWNERS sprawl, approval policy |
| CI time grows gradually | Pipeline throughput degrading | flaky tests, queue times, oversized workflows |
| Deploy time spikes intermittently | Release mechanics are inconsistent | GitOps sync health, manual gates, environment drift |
Filtering that makes the metric usable
Don't dump every service into one chart and call it a platform metric. Add filters that reflect how engineering operates:
- Repository or service
- Team or owning squad
- Environment
- Change type such as feature, fix, or infrastructure
- Deployment path such as direct CI deploy versus GitOps promotion
Those cuts matter because platform teams often inherit complaints that are really local workflow issues. The dashboard should let you prove whether the problem sits in one repo, one approval policy, or one release path.
A dashboard earns trust when engineers can drill from a summary number into the exact stage and change set that created it.
Keep the story operational
Annotate the dashboard with important process changes. If the team changed merge policy, moved to ArgoCD auto-sync, or reworked test parallelism, mark that date. Otherwise people will argue about causes from memory.
Also, show counts next to duration charts. A trend line without delivery volume can mislead fast. Even without turning this into a statistical thesis, context matters.
Avoiding Misleading Metrics and Finding Real Bottlenecks
Teams get into trouble when they treat cycle time like a vanity KPI. They chase a smaller number instead of understanding the system that produced it.
The first trap is using a simple average as the main view. Lean guidance is explicit here: cycle time is not one neat figure in real systems. It behaves like a distribution. Lean manufacturing guidance recommends measuring across multiple cycles, such as 20 cycles, and using the median or a percentile when variation is high because averages can mislead, as described in the Lean Enterprise Institute's cycle time guidance.
That principle matters even more in software than in factories. One blocked security review, one flaky integration suite, or one oversized pull request can distort the mean badly. Median and tail views give you a more honest picture of what most changes experience and what the worst cases look like.
The other confusion that wastes time
A lot of teams mix up cycle time and takt time. They are not interchangeable. Lean sources stress that takt time is demand-driven, while cycle time is your observed production rate, and they should be compared rather than substituted for one another, as explained in this discussion of cycle time versus takt time.
That distinction matters operationally. Cycle time tells you what your delivery system can do. Takt time tells you what incoming demand requires. You need both if you want to know whether the platform can keep up without creating backlog pressure.
Don't let the metric get gamed
A bad measurement culture creates fake improvements. Engineers learn quickly what the dashboard rewards. If leadership over-focuses on cycle time alone, teams can respond with smaller but less meaningful commits, premature PRs, or awkward ticket splitting that makes the metric look better while the customer experience stays the same.
Use cycle time as a diagnostic, not a quota. Inspect it alongside deployment patterns, failure signals, and the stage breakdown. The goal is to remove friction from delivery, not to train the organization to perform for the chart.
CloudCops GmbH helps teams design the platform foundations behind these metrics, including GitOps delivery, CI/CD pipelines, observability, and everything-as-code operating models. If you need a practical way to measure software flow across AWS, Azure, or Google Cloud without turning DORA reporting into a manual data project, see how CloudCops GmbH approaches platform and DevOps engineering.
Ready to scale your cloud infrastructure?
Let's discuss how CloudCops can help you build secure, scalable, and modern DevOps workflows. Schedule a free discovery call today.
Continue Reading
What Are DORA Metrics: Guide to Elite Software Delivery
Learn what are dora metrics. Measure & improve software delivery with benchmarks, tools, and a roadmap to elite performance in 2026.
Mastering Lead Time for Changes: Your 2026 Guide
Learn to measure & reduce lead time for changes, a key DORA metric. Discover benchmarks, bottlenecks, & strategies to accelerate your delivery pipeline.
DevOps Automation Services: Boost DORA Metrics
Discover DevOps automation services to boost DORA metrics. Our guide covers capabilities, evaluation, and roadmaps for 2026 success.