A dashboard can show short resolution times while defects in the backlog keep getting older. Before treating the charts as contradictory, inspect which defects each number represents. Recently resolved work and work still waiting for resolution are different populations. Quick closures can improve one measure without reducing the exposure carried by the other.
For a QA lead, the useful question is which outstanding defects need investigation, ownership, or a release decision. Average Age and Resolution Time support that discussion only when the work-item filter, Resolution field, dates, and reporting period are understood.
Atlassian's Cloud gadget reference describes Average Age as the average number of days that work items have been unresolved. It describes Resolution Time as the average resolution time, in days, of resolved work items. Start with those population definitions rather than comparing the heights of two bars.
An unresolved-age snapshot asks how old the currently unresolved defects are at a stated observation time. A resolved-duration cohort asks how long defects took from creation to resolution, selecting those resolved within a stated window. The first describes remaining work; the second describes work that reached a resolution. Neither mean alone establishes defect severity, testing completeness, or release readiness.
Also confirm the reporting surface available in your tenant. The general Cloud reference lists a Resolution Time dashboard gadget, while a separate Software Cloud knowledge-base article says a resolution-time report is unavailable for Software and Business projects and proposes a workaround. A project report and a dashboard gadget are different surfaces, but the documentation still warrants an availability check. Verify the exact gadget, project type, and configuration before promising a particular screen or output. The examples below are calculations, not observations from a Jira tenant.
Consider a fictional checkout team's defect ledger, DEFECT-AGE-UTC-1.0. All timestamps use UTC, and a day means 24 elapsed hours. The observation instant is 24 October 2026 at 00:00 UTC. The resolved cohort covers 1 October 2026 at 00:00 UTC inclusive through 24 October at 00:00 UTC exclusive. Only Bug work items qualify.
These boundaries are our teaching contract. They do not reproduce every historical bucket in a native Jira chart, its configured time zone, or its rounding behavior.
The unresolved snapshot contains five Bugs with an empty current Resolution field:
The resolved-window cohort contains AGE-C and AGE-D. AGE-C was created on 30 September at 00:00 and has a current Fixed resolution dated 3 October at 12:00, giving 3.5 elapsed days. Its visible status is In Progress. AGE-D was created on 2 October at 00:00 and resolved as Fixed on 4 October at 00:00, giving 2 days; its status is Done.
Two other records stay outside these calculations. AGE-E was created on 1 September and resolved on 29 September, both at 00:00, so its resolution precedes the selected window. AGE-I is an unresolved Task created on 1 September, excluded by the Bug-only scope. AGE-F's old resolved date is historical information, not a current resolved entry after Resolution was cleared.
For our unresolved snapshot, add 34, 13.5, 29, 23, and 22.5 days. The total is 122 days across five defects, giving a mean of 24.4 days. For the resolved cohort, add 3.5 and 2 days. The total is 5.5 days across two defects, giving a mean of 2.75 days.
The table preserves these fractional-day teaching means and adds one deliberately different rounding illustration. None of its means is a claimed native Jira gadget display.
Teaching Measure | Included Defects | Count | Total Days | Mean Days |
|---|---|---|---|---|
Unresolved age at 24 October, 00:00 UTC | AGE-A, AGE-B, AGE-F, AGE-G, AGE-H | 5 | 122 | 24.4 |
Resolution duration, 1 to 24 October (end excluded) | AGE-C, AGE-D | 2 | 5.5 | 2.75 |
Same resolved cohort, floor each duration first | AGE-C, AGE-D | 2 | 5 | 2.5 |
In the last row, we choose to round each positive duration down first: 3.5 becomes 3, and 2 remains 2. Averaging those values gives 5 / 2 = 2.5 days. Atlassian's JSM comparison says fractions of days are truncated, but that statement does not establish the order of truncation relative to aggregation or display. Our per-item-floor row demonstrates why the order needs checking; it does not assert Jira's implementation.
The gap between 24.4 and 2.75 days does not mean the team reduced the same defects' age by that amount. It means this fictional backlog contains older unresolved work alongside two relatively short resolved lifetimes. Investigate AGE-A and AGE-F, but inspect the data-quality mismatches before drawing a performance conclusion. A single snapshot and one resolved cohort also cannot establish a trend.
Jira's reporting distinction depends on the Resolution field, not only the status name. A populated Resolution makes a work item resolved; an empty field leaves it unresolved. The fictional AGE-B therefore remains unresolved despite Done, while AGE-C remains resolved despite In Progress. Those combinations are diagnostic signals to discuss with the workflow owner, not evidence that the team deliberately left work unfinished.
Atlassian documents two checks for potentially inconsistent records. Within the relevant project and defect scope, look for:
statuscategory = Done and resolution is EMPTYstatuscategory != Done and resolution is not EMPTYConfirm the reviewer's Browse projects permissions before interpreting an empty result as complete coverage. A saved filter is a saved search, and access to the filter does not establish access to every relevant work item. Record the filter identity and the account used for the review so another reviewer can investigate a population difference.
If the checks return records, inspect their transitions and Resolution values with the Jira administrator. Do not bulk-set Resolution merely to make a chart more reassuring. Atlassian recommends setting Resolution appropriately when work reaches an end state and clearing it when work reopens. Creating actual Resolution options named Unresolved or None is not a substitute for an empty field: those populated values still make Jira treat the item as resolved.
AGE-F illustrates a separate clock question. After reopening and clearing Resolution, our current unresolved-age calculation still starts at its original Created timestamp. It is 29 days old at the observation instant. Measuring from the reopening date would answer how long the latest open episode has lasted, which is a different measure. Do not silently replace one origin with the other.
For resolved work, the JSM comparison describes raw resolution duration as the latest Resolution date minus Created. It does not subtract every prior resolved interval or isolate time spent fixing the defect. If the review needs time in a particular status or a history of reopening cycles, inspect the corresponding history rather than infer it from these two timestamps.
The same comparison distinguishes the Resolution Time gadget's raw 24/7 elapsed time from JSM's Time to Resolution SLA reporting. An SLA can use business calendars and pause conditions; raw elapsed duration does not exclude nights, weekends, or waiting time. Compare like clocks before interpreting a difference as a reporting error or an SLA breach.
A current unresolved snapshot is not automatically the membership used by a monthly chart. Atlassian's knowledge-base article comparing Cloud and Server Average Age describes a Cloud monthly example with this creation-date condition:
created <= startofmonth()
The same sample also selects work that is unresolved or has a resolved date on or after the month's start. Keeping both conditions in view prevents the creation cutoff from being mistaken for the entire selection rule. The article is labeled Jira Service Management Cloud. Treat its precise expression as a documented example for that context, not a universal algorithm for every Jira Software Cloud report.
Apply only the creation boundary to our fictional UTC timestamps. AGE-G was created exactly at 1 October, 00:00, so it satisfies the less-than-or-equal comparison. AGE-H was created at noon that day and does not. AGE-B and AGE-D were also created after the boundary. Consequently, selecting the same broad defect filter does not guarantee that a monthly chart and a current unresolved list contain the same records.
This membership illustration does not calculate the native monthly bar. Check the target report's period, time zone, available configuration, and underlying records in your tenant before predicting its output. None of those tenant checks was performed for this example. A separate Atlassian calculation article is explicitly Data Center-only; its more detailed bucket explanation should not be imported as proof of Cloud behavior.
Use the charts to identify an investigation, then retain the records and assumptions behind it. A practical read-only review can follow this sequence:
A falling resolved-duration mean is useful evidence about the work that reached resolution, but it does not clear the outstanding backlog. Start the next defect review with the oldest relevant unresolved record and a verified Resolution state. Assign its next action before changing the reporting contract or celebrating a more reassuring average.
A tester reviewing a Jira issue may need a fresh smoke run without opening GitLab and choosing pipeline parameters. A manually triggered Jira Cloud…
A scheduled QA flow stops updating release-readiness notes. Some work items may already have changed, others may still be waiting, and the last visible…
A sprint can contain carefully estimated testing work and still overload the only person who can perform it. The missing input may be a…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
