Tickets we filed from audit findings that haven’t been resolved yet, the live backlog of things VortexIQ surfaced.
At a glance
Live count of Jira tickets that Vortex IQ filed from audit findings (Lighthouse regressions, broken structured data, broken canonical tags, payment-pixel misfires, abandoned-cart logic faults, accessibility violations, and the 200+ other audit signatures) where the ticket is still not in the done status category. This is the engineering-side accountability dial for everything Vortex IQ has surfaced as merchant-impacting.
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-based homewares brand on Shopify, around £4M GMV/year, with Vortex IQ connected for 8 weeks and a 3-engineer team using Jira Cloud. Reading taken at 09:30 GMT on 12 Mar 26.
The card reads 25 open at this snapshot, the alert at
>20 open is tripped (warn).
What this tells the merchant:
- The team is keeping pace overall but slipping on Medium-tier findings. 62 of 87 (71 percent) are resolved, healthy. But 13 Medium-tier findings are still open after 8 weeks, mostly SEO / accessibility issues that ship “when there’s time”, which is never. Pair with Abandoned Findings (>14d no movement) to identify which ones are stalled.
- The 2 open Critical findings are the priority read. Each represents a currently active revenue or compliance risk. One is the broken Apple Pay button on iOS 17.4+ that costs an estimated 4 to 6 percent of mobile checkout (Vortex IQ surfaced via
shopify.checkout_failure_ratecross-correlation); one is a missinghreflangblock on the/delocale that’s costing organic German traffic. Open the ticket detail page to triage; do not let critical findings wait for sprint planning. - The 9 open High findings are the next sprint’s natural backlog. A 3-engineer team can drain roughly 4 to 6 of these per sprint alongside BAU work. Two sprints to clear, assuming no new Highs land.
- The Critical-to-Resolved ratio is the leading indicator. When 50 percent of Critical findings stay open after 14 days, the merchant has a triage problem; when 80 percent resolve in 7 days the team is healthy. Today’s snapshot (50 percent Critical resolution, 9 days median) suggests a borderline-healthy triage rhythm.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Jira’s own dashboard: The matching native view is a saved JQL filter:Open Jira → Filters → Advanced issue search → paste the JQL above → Save as “Vortex IQ Open Findings”. Pin it to a Jira Dashboard gadget to give the engineering lead the same view as Vortex IQ’s Nerve Centre card.The card and the JQL filter should agree to within 1 to 2 tickets. Any larger gap usually means one of the reasons listed below. Why our number may legitimately differ from Jira’s filter:
Cross-connector reconciliation:
Known limitations / merchant FAQs
Why is this card on a non-engineering owner’s dashboard? Because every open VortexIQ finding represents a merchant-impacting issue that’s currently shipping to real customers: a slow page that’s losing conversions, a broken pixel that’s breaking paid attribution, a missing canonical that’s bleeding organic traffic. The number isn’t an engineering metric, it’s the unmitigated revenue risk currently sitting in the engineering queue. As a founder you don’t need to read each ticket; you need to know whether the queue is shrinking (team is absorbing risk) or growing (risk is accumulating). Open count is 25 but our team feels productive. What gives? Two patterns explain this. (1) Filing rate exceeded drain rate. Vortex IQ ran a fresh audit and filed 12 new findings; the team resolved 8 in the same period. Net change is +4 even though throughput is positive. Pair with Finding Resolution Rate (90d) to see the ratio. (2) Mediums are accumulating. Engineering teams happily resolve Criticals and Highs but quietly let Mediums and Lows pile up. The headline count masks the severity mix; click through to the Jira filter to see the distribution. My team uses a custom Jira workflow. Are tickets stuck in “Awaiting Deploy” counted as open? Yes. The card usesstatusCategory != done, not status name. Any custom status mapped to category to do or indeterminate counts as open. If you want tickets in “Awaiting Deploy” to stop counting, either (a) ask your Jira admin to map that status to category done (rare; usually only Done and Closed map to done), or (b) add a workflow transition that auto-closes the ticket when the deploy webhook fires.
A Vortex IQ finding has been auto-resolved by the audit engine but the ticket is still open. Why?
Vortex IQ files the ticket but does not auto-close it; the merchant team owns that lifecycle. If a finding self-heals (e.g. a CDN cache rebuild fixed the LCP regression without code changes), the ticket persists until someone reviews it and closes it. This is intentional, an auto-closed ticket can hide a recurrence; a human-closed ticket carries the deploy / config-change context. Pair with Avg Time-to-Fix and look for findings that resolved fast: those are often the self-heal cases worth a quick post-mortem.
Open count keeps growing. What is the playbook?
In order of likelihood: (1) Severity triage breakdown. Sort the open list by severity. If 80 percent are Medium / Low, the team is rightly prioritising paid work. Adjust the alert threshold in Vortex IQ to count only Critical + High. (2) Capacity gap. If Critical + High alone exceed 10, the team genuinely cannot absorb the queue, escalate to leadership. (3) Audit engine over-firing. If the same finding type files repeatedly, that’s signal the merchant has accepted a permanent technical-debt position; tag those finding-types as “wontfix” in the Vortex IQ audit-rules editor to suppress repeat filing. (4) Process bottleneck. Pair with Finding-to-Ticket Dispatch Lag, if dispatch lag is also high, the bottleneck is upstream of the team and the open count is symptomatic.
How does this connect to lost revenue?
Each finding has an estimated impact tag in the Vortex IQ audit (e.g. “estimated 4 to 6 percent of mobile checkout”). For a Critical finding the impact estimate maps to a £/day cost via Revenue at Risk when Datadog or NewRelic is also connected. Open count of 25 with cumulative estimated impact of £2,400/day means the open queue is bleeding £2,400/day until drained, that’s the conversation to have with the founder.
Why is the alert threshold 20 and not 10 or 50?
Calibrated against historical merchant data: open counts of 5 to 20 are normal for a small-team merchant doing ongoing maintenance; below 5 means the team is keeping pace; above 20 statistically correlates with growing customer-impact incidents downstream (CSAT drops, support volume rises, revenue dips on critical pages). Tune the threshold per organisation in Vortex IQ → Settings → Alerts → Jira.
Does this card include findings filed against a non-default Jira project?
By default no, the card respects the single-project scope set at connector setup. If the merchant operates multiple Jira projects and Vortex IQ files into more than one (configured in config/vortex_mind/manifests/jira.yaml under projects:), the card sums across all configured projects. Cross-project counting is exact, not estimated; the JQL is generated dynamically.
The number doesn’t update. What’s wrong?
Two checks. (1) API token TTL. If Atlassian Token Expiry Imminent is firing, the token expired and Vortex IQ stopped polling. Rotate the token in Vortex IQ → Settings → Connectors → Jira. (2) Rate-limit exhaustion. If Atlassian Rate-Limit Exhausted is firing, Atlassian throttled the polling. The card will catch up on the next available window; no action needed unless the rate-limit alert persists.