Log in Get started
Metric

What is cycle time, and how do you measure it in Metabase?

Cycle time is the elapsed time from when work starts to when it's done (completed_at − started_at). It measures active working time — how long an item takes once someone picks it up — and is the most actionable flow metric for engineering teams. Measure it in Metabase from issue-tracker data synced into a database (Linear or Jira).

TL;DR — Cycle time = started → done. It needs a reliable started_at (or status history). Lead time = created → done. Always report median (p50) and p90, not the average.

Why cycle time needs status history

started_at isn't always a stored column. The reliable way to know when work started is the status-change history: the first transition into an "in progress" state. If you only have a single resolved/completed_at timestamp, you cannot compute true cycle time — fall back to lead time and add a caveat.

  • Linear: use started_at if populated, or derive it from issue history (first move to a started workflow state).
  • Jira: derive from issue_changelog (first transition to an In Progress status); don't use resolved alone.

What data does cycle time need?

  • A reliable started_at, ideally from status-change history.
  • completed_at and a clear "done" definition.
  • For time-in-status breakdowns, the full status history (not just start/end).

SQL patterns

Median & p90 cycle time by weekPostgreSQL
SELECT
  date_trunc('week', completed_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (completed_at - started_at)) / 86400.0
  ) AS median_cycle_days,
  percentile_cont(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (completed_at - started_at)) / 86400.0
  ) AS p90_cycle_days
FROM issues
WHERE state_type = 'completed'
  AND started_at IS NOT NULL
GROUP BY 1 ORDER BY 1;

Pitfalls

No started_at.→ Without it (or history), you're really measuring lead time — say so.
Averages.→ Use median and p90; durations are heavily skewed.
Cross-team leaderboards.→ Use cycle time as a within-team trend, not a ranking.
Ignoring WIP.→ High work-in-progress usually inflates cycle time — show them together.

Where this metric applies

Dashboards

Software delivery dashboardSprint health dashboard

Metrics

Lead time

FAQ

Can I measure cycle time without status history?
Only if a trustworthy started_at exists — a timestamp for when work actually began. If all you have is a created date and a resolved/completed date, you're really measuring lead time, not cycle time. The reliable source for started_at is the status-change history: the first transition into an in-progress state (Jira's issue_changelog, Linear issue history). Without it, report lead time and caveat the gap.
What's the difference between cycle time and lead time?
Lead time measures created → done: the total wait a stakeholder experiences, including time sitting in the backlog. Cycle time measures started → done: only the active working period once someone picks the item up. Lead time is almost always longer, and the gap between them is queue/backlog time. Report both — lead time for customer-facing expectations, cycle time for team flow.
How is cycle time different from DORA lead time for changes?
They sound alike but measure different things. Cycle time here is an issue-tracker flow metric (started → done for a work item). Lead time for changes is a DORA delivery metric measured from first commit to production deploy, sourced from source control and CI/CD rather than the issue tracker.
Median or average cycle time?
Report the median (p50) and p90, never the mean. Duration data is heavily right-skewed — a handful of stalled tickets drag the average well above what a typical item experiences. The median shows the common case; p90 shows the tail your team should attack. The average hides both.
How do I reduce cycle time?
Cycle time tracks work-in-progress closely (Little's Law: less WIP in flight means faster completion), so cap concurrent work and finish before starting. Use the time-in-status breakdown to find where items wait — usually code review or a blocked/QA state — and split large issues into smaller ones, since smaller batches flow faster and forecast better.
Should I compare cycle time across teams?
No. Cycle time depends on work type, team size, and how issues are scoped, so cross-team leaderboards mislead and invite gaming. Use it as a within-team trend — is our median and p90 trending down? — not as a ranking between teams or individuals.
Where does cycle time apply — Jira or Linear?
Both. In Linear, use started_at if populated or derive it from the first move to a started workflow state. In Jira, derive it from the issue_changelog — the first transition into an In Progress status — rather than trusting resolved alone.