Every flow-metric tool makes choices — which clock to use, when an item counts as finished, how to take a percentile — and tools that choose differently show different numbers from the same Jira data. This page is FlowDeck's computation contract: the exact definitions behind every number its gadgets show. If a released definition ever changes, the change is announced in a release note — never silently.
FlowDeck is two dashboard gadgets. Once a Jira admin has installed the app from the Atlassian Marketplace, anyone who can edit a dashboard adds them from the dashboard's gadget picker, where they are listed as FlowDeck — Time in status and FlowDeck — Aging work in progress.
Each gadget asks for three things when it is added, and the same form reopens from the gadget's menu:
FD.Press Save. The first view of a project shows First-time setup while FlowDeck fetches that project's status history — larger projects take longer, and refreshing the dashboard shows progress. From then on the numbers refresh when viewed, at most every 15 minutes, and every view carries a "Data as of" line (see "Data as of" and freshness).
Time in status shows the total calendar time work items spent in each status of one project over the last 30, 60 or 90 days, as a table (status, total time, work items, average) or a bar chart. The table is sorted by total time in status, longest first — the sort is fixed and stated under the table. The average is the status's total divided by the number of work items that visited it.
Aging work in progress shows how long current work has been in progress, per status: how many work items sit in each status, the oldest age among them, and how many are over your team's own completed-cycle-time p50 and p85. Rows are sorted by oldest work item first. It shows aggregates only — no work item keys or per-item lists.
FlowDeck keys everything off Jira's three status categories — To Do, In Progress, Done — using your own site's status-to-category mapping, fetched live. It never hardcodes status names or ids.
It deliberately does not use board columns. One work item can sit on many boards, so board-relative "done" gives one item several answers; the category basis gives it one, and matches Atlassian Analytics and Atlassian's own Cycle Time Summary gadget. A work item in a status that maps to no category is disclosed in an accounting line, never silently dropped.
The sum of every visit a work item makes to a status, measured from the moment it enters to the moment it leaves. If an item bounces back into a status, the second visit adds to the same total — time is never erased by moving backwards. Time still accruing in an item's current status is included and said so on the gadget.
First entry into In Progress → last entry into Done, as elapsed calendar time. Everything between those two instants counts: waiting time, blocked time, rework after a reopen, and the time an item sat parked in Done before being reopened. A work item that went straight to Done without ever entering In Progress has no cycle time — it is excluded from cycle-time populations and the exclusion is counted and disclosed, never silently dropped.
Work item created → last entry into Done, as elapsed calendar time. This matches Atlassian Analytics, Azure DevOps and GitLab. Lead time is part of FlowDeck's computation contract; no shipped gadget currently displays it.
Work in progress means work items whose current status is in the In Progress category. An item's age runs from its first entry into In Progress to now — the same start anchor as cycle time, so an item's age becomes its cycle time the moment it finishes. A reopened item keeps aging from its original start; it does not reset. "Time in current status" is a different number and is never labelled as age.
The gadget compares current ages against the team's own completed cycle times from the configured comparison window: the reference line shows their p50 and p85, and the Over p50 / Over p85 columns count the work items in each status whose age is strictly greater than that percentile. A true zero shows 0; when percentiles are suppressed (see below) the cells show an em-dash instead.
A work item counts as finished when it enters the Done status category. FlowDeck never uses Jira's resolution field: resolution is structurally unreliable in practice — sites have born-resolved misconfigurations, reopening does not clear resolution without a hand-built automation, and team-managed projects have no Resolution field at all. See the comparison section for what this means next to Jira's own resolution-based reports.
3d 4h, 4h 12m, 12m. A positive value under a minute shows <1m; a true zero shows 0m. Days are 24-hour calendar days. Displayed values truncate rather than round up, so a duration is never overstated.0. An em-dash — marks a value that does not exist, which is different from both <1m and a true 0m.Percentiles use the nearest-rank method: p85 is the smallest observed value with at least 85% of items at or below it — always a value that actually occurred, which makes the service-level sentence literally true: "85% of items finished in this time or less." Example: for ten completed cycle times of 1, 2, 2, 3, 4, 5, 6, 9, 14 and 21 days, FlowDeck's p50 is 4 and p85 is 14. Methods that interpolate or take the floor rank report different values from the very same data (that dataset's floor-rank p85 is 9). FlowDeck shows p50 and p85, and uses no means or standard deviations to summarise flow-time distributions — cycle times and ages are only ever summarised by percentiles. (The time-in-status table's Average column is a different kind of number: a status's total time divided by the work items that visited it, per the definition above.)
Populations are never a bare count. Wherever a metric is computed over a population, FlowDeck discloses how many items were considered and every exclusion by reason, in a sentence like:
Below ten completed items, percentiles are suppressed. A percentile over a handful of items is noise dressed as insight, so the gadget shows the count and no percentile values at all:
FlowDeck's empty states say exactly what is known and no more. A time-in-status gadget with no data reports "No work items in the tracked window" and explains: "That covers both an empty project and one where all activity is older than the window" — the two really are indistinguishable, and the gadget doesn't pretend to know which. The aging gadget's empty state ("No work in progress") likewise covers both an empty project and one where all work sits in To Do or Done. Work items excluded from computation are always counted in a footer with their reason, e.g. "2 work items not included — couldn't be read from their change history."
None of these are bugs — they are different definitions producing different numbers from the same data. The most common ones:
| Tool / surface | Where the numbers diverge |
|---|---|
| OBSS Time in Status, SaaSJet Time in Status (business calendars) | Both offer working-hours/business-day calendars. FlowDeck counts 24/7 calendar time, so anything spanning a weekend carries roughly 48 more hours in FlowDeck than under a business calendar. |
| SaaSJet Time in Status (open items) | Excludes unfinished work items from its reports; FlowDeck includes still-accruing time and says so. FlowDeck's totals will read larger on projects with work in flight. |
| Atlassian Analytics | Uses whole-day arithmetic — (end − start) + 1, minimum one day — so short durations read larger; takes floor-rank percentiles, which report different values than nearest-rank on the same data; and its time-in-status erases time from backward moves, where FlowDeck sums every visit. |
| Jira Control Chart (boards) | Sums time in selected board columns rather than status categories, excludes the time an item sat parked in Done before a reopen, and draws a mean ± standard deviation band. FlowDeck's cycle time is first-In-Progress → last-Done elapsed time, with percentiles. |
| Jira "Cycle time report" (DevOps) | A different metric that shares the name: it measures first commit → production deployment from connected dev tooling, not status history. |
| Jira Created vs Resolved | Keyed on the resolution field, which FlowDeck never uses. On sites where done items lack a resolution (or open items carry one), the two will disagree. Diagnostic JQL to find the mismatch on your site: statuscategory = Done AND resolution IS EMPTY |
Naming collisions to keep in mind: DORA "lead time" is commit → production, and GitLab's cycle time is different again. FlowDeck's definitions are the status-history ones above.
FlowDeck computes with the app's own access, over all work items in the configured project — including items an individual viewer may not have permission to open. This is a deliberate stance: dashboard gadgets are shared team radiators, and per-viewer computation would make everyone's numbers different. What any viewer sees is aggregates only — durations, counts and percentiles. No work item key, id or per-item value is displayed, and none is even sent to the browser.
Before a gadget shows you a project's numbers, FlowDeck checks — as you, on every view — that your Jira account can browse that project. If it can't, or the project doesn't exist, the gadget says "Project not visible to you" and shows no numbers; the same check runs when a project key is saved in the gadget's form. Within a project you can browse, the aggregates still include work items an issue security level hides from you.
Archived work items are not counted, because they are invisible to Jira search. Every search-driven surface in Jira, native reports included, loses archived work the same way. Deleted work items likewise drop out of the numbers — at the next refresh for items in progress, and within a day otherwise.
FlowDeck computes from the status history Jira has recorded. For work items brought in by an import, history often begins at the import: nothing on the surface can distinguish "sat in Done for 37 days" from "has existed for 37 days with no recorded history". On import-heavy projects the second is the common case — treat long quiet residencies on imported items with that in mind.
Numbers refresh when viewed, at most every 15 minutes; the first view of a project shows a "First-time setup" state while FlowDeck fetches its status history. The "Data as of" line stamps when data was last ingested. Still-accruing time keeps counting between ingestions, so totals can move between views while the stamp stays the same — that is by design, not a stuck refresh. If a refresh is due the line appends "update due"; if one failed, the gadget keeps the last good numbers and says "last update failed" rather than going blank.
The bar chart is for comparison, not measurement: its tooltips and axis compact values to about two significant figures. The table carries exact values — and the chart's own menu offers "View data table" with full precision.
Long tables paginate — every row stays reachable, and pagination is a viewport concession, never a cap. If any FlowDeck surface ever has a hard limit, it will say "showing X of Y" rather than quietly dropping rows.