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.
| What it counts | COUNT(jira.tracker_item) joined to audit_finding on the vortexiqFindingId custom field, filtered to statusCategory != 'done'. Includes both to do (untouched) and indeterminate (in-progress) buckets. |
| Project / board scope | The Jira project chosen at connector setup (typically the merchant’s primary engineering project). Cross-project counting is supported when the merchant configures a multi-project filter in the manifest, but defaults to single-project to avoid double-counting in companies that fork tickets across teams. |
| Status filter | Anything except statusCategory = 'done'. The card respects Jira’s status category abstraction (to do / indeterminate / done), not the merchant’s custom workflow names, so a custom status like “Awaiting QA” or “Deployed to Staging” still counts as open. |
| Issue type filter | All issue types are counted by default (Bug, Task, Story, Improvement, Sub-task all qualify). Vortex IQ files findings as Bug for severity-critical / high and as Task for severity-medium / low; the merchant can override per-finding-class in the manifest. |
| Resolution vs closed | Tickets in Resolved (with a resolution set) but not yet transitioned to Done are counted as open by default. Some merchant workflows park tickets in Resolved indefinitely; pair with Avg Time-to-Fix to detect that pattern. |
| VortexIQ-only scope | Tickets that did not originate from Vortex IQ (the team’s own bugs, BAU work) are excluded by the vortexiqFindingId IS NOT NULL join condition. For total open tickets see Open Tickets. |
| Merchant impact link | Every ticket here represents a merchant-impacting issue: a slow LCP page (lost conversions), a broken hreflang (lost SEO), a misfiring purchase pixel (broken paid attribution), an inaccessible checkout button (lost orders + ADA risk). The count is a proxy for unmitigated revenue / compliance risk currently in the engineering queue. |
| Refresh cadence | Real-time. JQL polled every 60 seconds via GET /rest/api/3/search. |
| Time window | RT (live count, no period boundary). |
| Alert trigger | >20 open. The threshold is calibrated against typical merchant capacity: more than 20 open VortexIQ findings means the queue is draining slower than the audit engine is filling it, the merchant team is falling behind. |
| 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-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.| Severity | Findings filed (8w cumulative) | Currently open | Currently in progress | Resolved (90d) | Open count |
|---|---|---|---|---|---|
| Critical (revenue-blocking) | 4 | 1 | 1 | 2 | 2 |
| High (conversion-impacting) | 18 | 6 | 3 | 9 | 9 |
| Medium (SEO / a11y) | 41 | 12 | 1 | 28 | 13 |
| Low (best-practice) | 24 | 1 | 0 | 23 | 1 |
| Total | 87 | 20 | 5 | 62 | 25 |
>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
| Card | Why pair it with VortexIQ Findings Open | What the combination tells you |
|---|---|---|
| VortexIQ Findings In Progress | The work-in-flight subset of this card. | Open count high but In-Progress count low equals queue stalled at triage; both moving means active engineering throughput. |
| VortexIQ Findings Resolved (90d) | The 90-day drain history. | Resolved trending up while open holds equals balanced steady state; resolved trending down equals team capacity issue. |
| Abandoned Findings (>14d no movement) | Subset of open with zero status changes in 14 days. | A high open count made up mostly of abandoned tickets is a process failure, not a capacity failure. |
| Finding Resolution Rate (90d) | The percentage view, resolved over filed in window. | Below 50 percent equals filing faster than draining; the open count is a lagging visualisation of that imbalance. |
| Avg Time-to-Fix (days) | Speed of the drain. | Open count of 25 with 5-day TTF is healthy; open count of 25 with 21-day TTF is a slow-bleed failure. |
| Critical Findings Without a Jira Ticket | Coverage gap, the un-filed counterpart to this card. | Open >20 here while Critical-no-ticket >0 means the engineering team is busy with old findings while new criticals are being missed. Worst possible shape. |
| Finding-to-Ticket Dispatch Lag | Time from audit detection to Jira ticket creation. | If dispatch lag is climbing AND open count is climbing, the bottleneck is dispatch + triage (process), not drain (capacity). |
| Open Tickets | Total Jira open count, all sources. | VortexIQ findings as a share of total open tickets shows the team’s prioritisation, healthy is 30 to 50 percent. |
| Cross-connector: Datadog Active Incidents | Operational-side incidents that often overlap with VortexIQ findings. | A Critical VortexIQ finding plus an active Datadog SEV-1 on the same service is a single story, treat as one P1. |
| Cross-connector: Shopify Checkout Failure Rate | The merchant-impact metric many Critical VortexIQ findings drive. | If checkout failure is up while critical VortexIQ findings stay open, you can quantify the revenue cost of the open queue. |
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:
| Reason | Direction | Why |
|---|---|---|
| Polling cadence | Ours lower for “just now” | Vortex IQ polls Jira every 60 seconds; tickets created or transitioned in the most recent minute may not yet appear. The Jira UI is real-time. Refresh after 60 seconds and the numbers reconverge. |
| Custom field name | Ours zero if mismatched | The card joins on a Jira custom field named “Vortex IQ Finding ID” (default field key customfield_NNNNN). If your Jira admin renamed the field, the card silently shows zero until the manifest is updated to match. |
| Project scope | Ours lower if multi-project | The card defaults to the single project chosen at connector setup. If the team forks Vortex IQ tickets into a second project, those don’t appear here unless the manifest is configured for cross-project. |
| Permission scheme | Ours lower if narrowed | The Atlassian API token’s user must have Browse Projects permission on every project Vortex IQ files into. If a permission scheme was tightened post-setup, hidden tickets vanish from the card. |
| Status workflow | Ours higher if “Done” not used | If the team uses a custom status like “Closed” without setting statusCategory = done, those tickets keep counting as open. Either fix the workflow’s category mapping in Jira admin, or the card will overstate. |
| Soft-delete / archive | Ours unchanged | Jira’s archive feature does not flip statusCategory; archived issues with statusCategory != done still count. Pair with Oldest Open Ticket Age to spot stale archives. |
| Card | Expected relationship | Causes of legitimate divergence |
|---|---|---|
audit_finding registry inside Vortex IQ | Open ticket count plus unfiled critical findings should equal the Vortex IQ audit-finding open queue. | Dispatch lag (some findings still pending Jira creation), merchant-disabled auto-dispatch, ticket creation rate-limited by Jira. |
datadog.dd_incidents_active | No mathematical identity, but operational overlap. | A Critical VortexIQ finding on a checkout regression and a Datadog SEV-1 on the same service are different views of the same merchant problem. Track both. |
newrelic.nr_alert_active_count | Independent peer to Datadog incidents. | Same as above, alternative monitoring stack. |
shopify.checkout_failure_rate, bigcommerce.bc_cart_abandonment | The merchant-outcome that many Critical VortexIQ findings cause. | Open count climbing with checkout failure climbing equals the engineering queue is failing to absorb merchant-impacting risk fast enough. |
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.