What share of audit findings actually got fixed via the Jira pipeline. <50% means we’re filing faster than the team drains.
At a glance
The percentage of Vortex IQ-filed Jira issues that the merchant team has actually closed in the last 90 days. Designed to answer the merchant question: “is the audit programme working, or am I paying for findings nobody fixes?” On engineering-led merchants this is the single best signal of audit-programme health. A green reading (>75%) means audit insight is converting into shipped fixes; amber (50 to 75%) means the team is straining; red (<50%) means findings are filed faster than the team can drain them and the audit programme is not paying for itself.
Calculation
Calculated automatically from your Jira data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK 30-person ecommerce engineering team using Jira Software Cloud Premium. Three projects connected (ENG, OPS, MKT). Snapshot taken on 02 May 26 at 11:45 BST, looking back over the rolling 90 days from 02 Feb 26.
The card reads 68%, sitting in the amber band. Six observations:
- The rate is mathematically anchored on the filing date, not the closure date. A finding filed on 04 Feb 26 and closed today still counts in the numerator; a finding filed 12 Mar 26 and still open today counts against. The rate becomes harder to keep green as the audit programme matures and findings accumulate; new merchants see green easily, mature programmes need disciplined triage.
- 68% is the engineering-team benchmark for healthy audit programmes. Below 50% means findings are filed faster than the team ships; above 75% means the team has slack. The sweet spot for an engineering-led audit is 60 to 80%, where Vortex IQ is filing enough findings to keep the team busy but not drowning. If the rate stays above 90% for a quarter, consider lowering the audit threshold (more findings filed) because the team has capacity.
- The 14
Won't Fixresolutions are healthy triage, not failure. A team that confidently marks 9% of findingsWon't Fix(with comments explaining why) is making good prioritisation decisions. A team where 40%+ of resolutions areWon't Fixis using the resolution as a dump-truck for findings they do not want to engage with; investigate the comments and confirm the signals are genuinely out-of-scope. - The MKT (marketing tech) project is dragging the rate. Across the 156 findings, the MKT project filed 22 and closed 9 (41%); below the 50% alert threshold for that subproject. Marketing-tech findings often wait for sprint planning at the start of each sprint cycle; tune the abandonment threshold for MKT to 21 days if this is a recurring pattern, and ensure marketing-team sprint planning explicitly includes Vortex IQ findings.
- Pair with
jir_vortexiq_findings_openandjir_vortexiq_findings_abandoned. Resolution > 75% with open count climbing means the audit programme is over-finding for the team’s capacity, not under-fixing. Resolution < 50% with abandoned rising means the team is starting findings then stalling, not refusing the work. - Reconcile with
shopify.refund_rate. If refund rate is steady or falling AND this card is at 68%, the audit programme is paying for itself; the dropped findings (Won't Fix) are correctly the lower-impact ones. If refund rate is climbing despite 68% resolution, the team is closing the wrong findings (cosmetic ones over revenue-impacting ones); audit which categories are landing asDoneversusWon't Fix.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Jira’s own dashboard: Jira does not provide a single “tag-scoped resolution rate” gauge, so this card is computed from JQL searches. To verify it manually:Atlassian Analytics (Premium / Enterprise) build a chart with two series: numerator JQLWhy our number may legitimately differ from the manual calculation:labels = "vortex_iq_finding" AND resolution IS NOT EMPTY AND created >= -90d; denominator JQLlabels = "vortex_iq_finding" AND created >= -90d. Display the ratio. Issue Search with the two queries above; the numbers in the result-count footer give the same calculation. Jira Dashboard build two “Filter Results” gadgets (one per JQL) and compute the ratio mentally; or use the “Pie Chart” gadget grouped byresolution.
Cross-connector reconciliation:
Known limitations / merchant FAQs
The rate dropped 15 points this week. What changed? Three usual causes, in order of likelihood:- Audit volume up. Vortex IQ filed more findings than usual (a fresh catalogue audit, a payment-funnel audit, a SEO sweep). The denominator grew faster than the team’s closure rate. Often resolves itself within 2 to 3 weeks as the team clears the new findings.
- Capacity loss. A senior engineer on PTO, a key person on a feature deploy, or a temp churn. Pair with Sprint Velocity; if velocity is also down, capacity is the answer.
- Triage-process drift. Sprint planning stopped including Vortex IQ findings, or a workflow rule turned off. Open Project Settings, Workflows and confirm Vortex IQ-related automations are still active.
- 75%+ : healthy. Audit programme is working; team has slack.
- 60 to 75% : normal for a maturing programme. Acceptable.
- 50 to 60% : warn. Team is straining; investigate triage process.
- <50% : critical. Findings filed faster than they are closed. Audit programme is not paying for itself.
Won't Fix is counted as resolved. Is that right?
Yes, by design. Won't Fix reflects a triage decision (out-of-scope, duplicate, no-longer-relevant) which is just as important to the audit programme as a Done resolution. A team that confidently marks 10 to 25% of findings Won't Fix is making good prioritisation decisions. If Won't Fix is more than 30% of resolutions, it suggests the team is using it as a dump-truck rather than as triage; investigate the comments and confirm the resolution is genuine.
Why does the rate sometimes climb without anyone closing tickets?
Older findings drop out of the 90-day window over time. A finding filed 91 days ago that was open yesterday is silently removed from the denominator today. This is correct behaviour but can confuse merchants who expect the gauge to be motion-tied. Don’t chase 1 to 2 point movements; look at the trend over a 14-day window.
A reopened issue dropped my rate by 1 point. Can I exclude it?
A resolved issue that gets reopened is genuinely no longer resolved, so the rate correctly drops. If reopens are common (>5% of resolved tickets), it points to a quality-of-fix problem; fixes are landing but not actually resolving the underlying issue. Triage why reopens are happening before excluding them.
My team uses custom resolution types. How does the card classify them?
The card treats any non-empty resolution field as resolved. Custom resolution types (e.g. Deferred to Q3, Out of Scope) all count as resolved. If you want a stricter “Done-only” view, build a separate Atlassian Analytics chart with resolution = "Done" as the numerator filter.
Multi-project: my account spans three projects. Why does the gauge show a single number?
The card aggregates by default. To break out by project, open the per-project stack panel from the Vortex IQ Nerve Centre, or build three Atlassian Analytics charts.
Reopen-rate is rising AND this card is dropping. What is the play?
Both falling together is the strongest signal that the team is closing tickets prematurely under sprint pressure rather than actually shipping fixes. Sit with the engineering lead and tighten the definition-of-done on Vortex IQ tickets; require a code-deploy reference, a screenshot, or a test-case in the closing comment.
Why is the alert threshold 50% and not 70%?
50% is the breakeven point at which the team is closing one finding for every one filed. Below 50% the backlog grows mathematically; above 50% it shrinks. A 70% threshold would over-page in the first quarter of any new audit programme, when finding volume legitimately exceeds team capacity by design. Tune the threshold per organisation in Vortex IQ, Settings, Alerts.
Atlassian’s Done resolution gap: what do I do?
Audit your Jira workflows. For every status that lands in the Done column, confirm the transition into that status sets the resolution field. Atlassian’s documentation calls this the “Done resolution gap”; it’s the most common workflow misconfiguration on Jira Cloud. The fix is a one-time workflow edit per project; the result is that this card becomes accurate.
My team uses Jira but the resolution rate looks much better in Linear-using teams I know. Is something wrong?
Probably not. Linear’s smaller backlog and faster cycle time naturally produce higher resolution rates than Jira (Linear is engineering-purist; Jira is cross-functional). The card’s threshold (50%) accounts for Jira’s typical operating range; Linear-using teams often see 80%+ on the equivalent card. The right comparison is to the same team’s prior 90-day rate, not to other tools’ teams.