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

Cycle time is the elapsed time from when work startsto 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).

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

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

Where this metric applies

• Linear + Metabase — started_at or first started workflow state
• Jira + Metabase — first In Progress transition in the changelog

Related

Dashboards

Metrics

FAQ