> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Finding Resolution Rate (90d), Jira > What share of audit findings actually got fixed via the Jira pipeline. <50% means we're filing faster than the team drains. How to read it, why it matters,... **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Project Management](/nerve-centre/connectors#connectors-by-type) > 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 card reads **68%**, sitting in the amber band. Six observations: 1. **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. 2. **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. 3. **The 14 `Won't Fix` resolutions are healthy triage, not failure.** A team that confidently marks 9% of findings `Won't Fix` (with comments explaining why) is making good prioritisation decisions. A team where 40%+ of resolutions are `Won't Fix` is 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. 4. **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. 5. **Pair with [`jir_vortexiq_findings_open`](/nerve-centre/kpi-cards/jira/vortexiq-findings-open) and [`jir_vortexiq_findings_abandoned`](/nerve-centre/kpi-cards/jira/abandoned-findings).** 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. 6. **Reconcile with [`shopify.refund_rate`](/nerve-centre/kpi-cards/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 as `Done` versus `Won't Fix`. ## Sibling cards merchants should reference together | Card | Why pair it with Finding Resolution Rate | What the combination tells you | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | | [VortexIQ Findings Open](/nerve-centre/kpi-cards/jira/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)](/nerve-centre/kpi-cards/jira/abandoned-findings) | 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)](/nerve-centre/kpi-cards/jira/avg-time-to-fix) | 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](/nerve-centre/kpi-cards/jira/sprint-velocity) | The throughput signal. | Velocity flat + rate falling = findings being filed but not planned into sprints. | | [Won't Fix Resolution Share](/nerve-centre/jira/jir_wontfix_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)](/nerve-centre/kpi-cards/shopify/refund-rate) | The downstream truth metric. | Refund rate falling + rate at 60%+ = programme paying for itself. | | [Customer Service Sentiment](/nerve-centre/shopify/customer_service_sentiment) | The retention-side outcome. | Rate climbing + sentiment climbing = the audit story works for the CXO. | | [Datadog Health Score](/nerve-centre/kpi-cards/datadog/operational-health-score) | Sibling-platform health for technical findings. | Both green = balanced engineering culture; reliability holding and audit work keeping pace. | | [Open Tickets (all)](/nerve-centre/kpi-cards/zendesk/open-tickets) | 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](https://yoursite.atlassian.net/jira/analytics) (Premium / Enterprise) build a chart with two series: numerator JQL `labels = "vortex_iq_finding" AND resolution IS NOT EMPTY AND created >= -90d`; denominator JQL `labels = "vortex_iq_finding" AND created >= -90d`. Display the ratio. > [Issue Search](https://yoursite.atlassian.net/issues/?jql=) with the two queries above; the numbers in the result-count footer give the same calculation. > [Jira Dashboard](https://yoursite.atlassian.net/jira/dashboards) build two "Filter Results" gadgets (one per JQL) and compute the ratio mentally; or use the "Pie Chart" gadget grouped by `resolution`. **Why our number may legitimately differ from the manual calculation:** | 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. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes legitimate divergence | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | [`shopify.refund_rate`](/nerve-centre/kpi-cards/shopify/refund-rate) / [`bigcommerce.refund_rate`](/nerve-centre/kpi-cards/bigcommerce/refund-rate) / [`adobe_commerce.refund_rate`](/nerve-centre/kpi-cards/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`](/nerve-centre/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`](/nerve-centre/kpi-cards/datadog/operational-health-score) | Independent peer; correlates only when audit is dominantly technical. | Both green = balanced engineering culture. |
Documentation cross-reference (for agencies running multiple PM tools) The "Finding Resolution Rate" metric exists with the same definition on every PM tool we connect to. This is **not** a reconciliation; the merchant typically uses one PM tool. * [`linear.lin_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/linear/finding-resolution-rate) * [`asana.asa_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/asana/finding-resolution-rate) * [`clickup.cli_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/clickup/finding-resolution-rate) * [`monday.mon_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/monday/finding-resolution-rate) * [`zendesk.zen_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/zendesk/finding-resolution-rate)
## Known limitations / merchant FAQs **The rate dropped 15 points this week. What changed?** Three usual causes, in order of likelihood: 1. **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. 2. **Capacity loss.** A senior engineer on PTO, a key person on a feature deploy, or a temp churn. Pair with [Sprint Velocity](/nerve-centre/kpi-cards/jira/sprint-velocity); if velocity is also down, capacity is the answer. 3. **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. **A finding closed today but it was filed 95 days ago. Does it count?** **No.** The window is anchored on the **filing** date, not the closure date. A finding filed outside the 90-day window does not appear in the denominator at all, even if it just closed. This avoids "closed an old ticket today" gaming the metric. **What is a healthy rate?** * 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. **Should I optimise for a higher rate?** Not necessarily. A rate above 90% sustained for a quarter often means the audit thresholds are too generous (finding only obvious issues). Lower the audit threshold to surface more borderline issues; the rate will dip but the merchant outcome (lower refund rate, lower customer-service load) will improve. **`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. *** ### Tracked live in Vortex IQ Nerve Centre *Finding Resolution Rate (90d)* is one of hundreds of KPI pulses Vortex IQ tracks across Jira and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.