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.
| What it counts | resolved_findings_90d ÷ (resolved_findings_90d + open_findings_90d) × 100, expressed as a percentage of Vortex IQ-tagged Jira issues created in the last 90 days that have a non-empty resolution field today. |
| Numerator | Issues with labels = "vortex_iq_finding" AND resolution IS NOT EMPTY AND created >= -90d. Includes resolutions of Done, Won't Fix, Cannot Reproduce, and Duplicate; the card does not distinguish between them. |
| Denominator | All issues with labels = "vortex_iq_finding" AND created >= -90d, regardless of state. |
| Status filter | All open statuses count as unresolved; any non-empty resolution counts as resolved. The card uses the resolution field (not the status) because Jira workflows can put issues in a “Done”-looking column without setting resolution; the resolution field is the canonical close signal. |
| Issue type filter | All Vortex IQ-tagged issue types included (Bug, Story, Task, custom types). Sub-labels (vortex_iq:checkout, vortex_iq:catalogue) do not filter the rate; they exist for breakdown views. |
| Project / board scope | All Jira projects tagged vortex_iq_outbound in connector setup. Multi-project merchants see a blended rate; per-project stack panel available. |
| Resolution counts | Done, Won't Fix, Cannot Reproduce, and Duplicate all count as resolved. Won't Fix resolutions deliberately count as resolved because they reflect a triage decision; an audit team that closes 60% as Won't Fix is still doing the work, even if not shipping fixes. |
| Reopened issues | If an issue is resolved then reopened within 90 days, it counts as unresolved at the moment of measurement. |
| API endpoint | POST /rest/api/3/search/jql with two JQL queries (numerator and denominator), refreshed every 60 seconds. The count endpoint returns integers without payloads, so refresh is fast even on large backlogs. |
| Time window | 90D rolling. The rate is anchored on the filing date, not the closure date; a finding filed >90 days ago that closed today does NOT count in either side of the rate. |
| Alert trigger | <50%. At 50% the team is leaving as many findings open as it closes; below 50% the backlog grows mathematically. |
| Sentiment thresholds | Good >= 75%, warn 50-75%, critical <50%. |
| Time zone | Jira’s created and resolutiondate are stored as UTC; the 90-day window uses UTC boundaries. |
| Roles | owner, operations |
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.
| Bucket | Count | Notes |
|---|---|---|
| Vortex IQ issues filed in window | 156 | Roughly 1.7 per day across three projects |
Resolved as Done | 78 | Shipped fixes |
Resolved as Won't Fix | 14 | Out-of-scope or duplicate; deliberately closed |
Resolved as Cannot Reproduce | 6 | Audit signal cleared without explicit fix |
Resolved as Duplicate | 8 | Found to overlap an existing engineering ticket |
| Total resolved | 106 | All resolution types |
| Still open across all projects | 50 | In Backlog, To Do, In Progress, Blocked |
| Resolution rate | (106) / 156 = 67.9% | Amber, above 50% but below 75% |
- 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
| Card | Why pair it with Finding Resolution Rate | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | The unresolved-count denominator-side counterpart. | Open count high + resolution rate low = findings filed but never closed; the worst possible state. |
| Abandoned Findings (>14d no movement) | The silent-leak subset. Abandoned findings are guaranteed denominators with no numerator contribution. | Abandoned rising while this rate falls = the team is losing ground on the audit queue specifically. |
| Avg Time-to-Fix (days) | Cycle-time peer. The rate tells you whether findings close; this tells you how fast once they do. | Rate green + time-to-fix slow = team eventually ships but late; rate red + time-to-fix fast = team ships some quickly and abandons the rest. |
| Sprint Velocity | The throughput signal. | Velocity flat + rate falling = findings being filed but not planned into sprints. |
| Won’t Fix Resolution Share | The triage-quality signal. | If Won't Fix is more than 30% of resolutions, the team may be using it as a dump-truck rather than as triage. |
| Refund Rate (Shopify / BigCommerce / Adobe) | The downstream truth metric. | Refund rate falling + rate at 60%+ = programme paying for itself. |
| Customer Service Sentiment | The retention-side outcome. | Rate climbing + sentiment climbing = the audit story works for the CXO. |
| Datadog Health Score | Sibling-platform health for technical findings. | Both green = balanced engineering culture; reliability holding and audit work keeping pace. |
| Open Tickets (all) | Total CX backlog, when Zendesk-or-similar is also connected. | Both elevated = team overloaded across the board; rate dropping in isolation = findings deprioritised specifically. |
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.
| Reason | Direction | Why |
|---|---|---|
| Time zone | None expected | Jira and the card both use UTC for created and resolutiondate; gap is rare. |
| Resolution-field semantics | Ours stricter | The card uses resolution IS NOT EMPTY as the close signal. Some teams transition issues to Done status without setting resolution (a workflow misconfiguration); these stay in our denominator without contributing to the numerator. Audit Jira workflows for this Done resolution gap. |
| Cross-project aggregation | Either | Card aggregates across all vortex_iq_outbound projects; the manual JQL may scope to one project. |
| Reopened issues | Same in both | Jira’s resolution field is cleared on reopen; both views see this. |
| Filing-date anchoring | Either | The card anchors on created. A finding closed today filed >90 days ago does NOT count; a finding still open today filed exactly 90 days ago does count against. Some manual JQLs use resolutiondate >= -90d for the numerator instead of created >= -90d, which produces a different rate. |
| API rate-limit lag | Up to 30s stale | Jira Cloud rate-limits search at 100/min for free tier and 500/min for Standard+. |
| Won’t Fix inclusion | Same in both | The card counts Won't Fix as resolved; this is the standard interpretation but some teams want to see Done-only. Build a separate JQL with resolution = Done if you want that view. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
shopify.refund_rate / bigcommerce.refund_rate / adobe_commerce.refund_rate | Inverse correlation. Higher resolution rate should reduce refund rate over a 4 to 8 week trailing window. | Resolution rate up + refund rate up = team is closing low-impact findings; resolution rate down + refund rate down = findings were duplicates. |
shopify.customer_service_sentiment | Positive correlation, 2 to 4 week lag. | Sustained 70%+ resolution rate predicts CSAT lift of 2 to 4 points within a quarter. |
datadog.dd_health_score | Independent peer; correlates only when audit is dominantly technical. | Both green = balanced engineering culture. |
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.