Issue Lifecycle Report
Last updated: October 27, 2026
The Issue Lifecycle report shows how long completed issues spend waiting (To Do) and being worked on (In Progress), and, if you configure custom stages, how long they spend in each step of your own workflow.
Why it matters
Tracking time in each stage shows where work gets stuck, so you can make decisions about capacity, process, and planning from data. The report helps you see:
How long issues spend in To Do and In Progress
Which workflow stages are bottlenecks
Team throughput and completion rates
Trends in delivery over time
How it works
Status categories. Span maps every status in your tracker to one of three categories:
Tool | What Span reads |
|---|---|
Jira | Each status's category in your Jira workflow: To Do (gray), In Progress (blue), Done (green) |
Linear | The workflow state type: Triage, Backlog, and Unstarted are To Do; Started is In Progress; Completed and Canceled are Done |
Azure Boards | The state category, falling back to the state name for renamed or removed states |
GitHub Issues | The GitHub Projects Status field, matched by name, plus open at creation and done at close |
How time is calculated.
Span records a timestamp each time an issue changes status.
It measures each status visit, from the change into the status until the next change. The issue's current status has no end yet, so it doesn't count.
It sums the visits in each category, including repeat visits after an issue moves backward.
If your organization excludes weekends, it removes weekend time using your organization's time zone.
Metrics:
Metric | What it measures |
|---|---|
Time in To Do | Total time a completed issue spent in To Do statuses |
Time in In Progress | Total time a completed issue spent in In Progress statuses |
Issue Lifecycle | Average Time in To Do plus average Time in In Progress: waiting time plus working time. Lower is better |
Time in Stage | Time spent in the statuses you mapped to one of your custom stages |
Issues Completed / Week | Done issues ÷ non-out-of-office person-days × 7. Weekends count as active days |
Issue Completion Rate | Done issues ÷ all issues in the date range |
PR Link Rate | Merged PRs linked to an issue ÷ merged PRs |
Time metrics offer Average (capped at 30 days per issue), P50, P75, P90, and Max, and show values in hours and minutes. Percentiles show the distribution: P75 = 5 hours means 75% of issues spent 5 hours or less in that stage.
How to set up Issue Lifecycle
Prerequisites: an integration with Jira, Linear, Azure Boards, or GitHub Issues, and issues with status history.
The To Do and In Progress metrics work without setup. To add your own stages:
Go to Settings → Metrics, find the Issue Lifecycle Report card, and click Configure Substages.
Create named stages inside each of the three categories, To Do, In Progress, and Done. Each category allows up to 10 stages.
Assign each status from your tracker to a stage. Each status can belong to one stage. The page shows mapping statistics and warns about unmapped statuses.
Save. Span recomputes stage time for your full history on its next data run.
Example configuration:
To Do
└── Backlog → Status: "New", "Open"
└── Ready for Development → Status: "Ready", "Prioritized"
In Progress
└── Development → Status: "In Progress", "Working"
└── Code Review → Status: "Review", "PR Open"
└── Testing → Status: "QA", "Testing"
Done
└── Completed → Status: "Done", "Closed", "Merged"Find the report in Insights → Productivity → Velocity → Issue lifecycle. Viewing it needs the Issue Tracking permission. Filter and group by team, assignee, issue type, and other dimensions.
Things to know
Worked example: an issue is created Monday 9:00 in Backlog (To Do), moves to In Progress Monday 14:00, to Code Review (In Progress category) Tuesday 16:00, and to Done Wednesday 10:00. Time in To Do is 5 hours. Time in In Progress is 26 + 18 = 44 hours. Issue Lifecycle for this issue is 49 hours.
Completed issues only: Time in To Do and Time in In Progress count issues whose current status is Done. Open issues show up once they close. Time in Stage also includes the finished stages of issues still in progress.
Issue Lifecycle adds two averages: it isn't the average of each issue's total. If many issues skip To Do, the sum can overstate a typical issue's total.
Names and categories must match: a status counts toward a custom stage only when its name matches exactly and it sits in the same category in your tracker. If you map "QA" under In Progress but Jira puts QA in the To Do category, the stage stays empty.
Unmapped statuses: statuses you leave out of every stage drop from the stage view but still count in the To Do and In Progress totals.
Done stages rarely show time, because most issues stay in their final Done status and Span doesn't count the current status.
Every issue type counts, including epics, sub-tasks, and bugs. Filter by issue type to narrow it.
Assigned issues only: report views keep issues assigned to someone Span can match to a person.
No AI inference: calculations come straight from status history.
Issue Lifecycle and PR cycle time: Issue Lifecycle tracks work through your tracker's statuses. PR cycle time tracks code from the first commit to merge. Together they give end-to-end visibility.
Two stage counts: "Total Issues by Lifecycle Stage" counts issues currently in a stage. The historical version counts every issue that has ever finished time in that stage.
Related articles
How to setup weekend exclusion for metrics
Need help?
Contact your Span account team or reach out to support@span.app.