Critical / high audit findings older than 7 days with no Jira ticket, coverage gap. The auto-dispatch missed these or the merchant disabled it; either way, money on fire.
At a glance
The coverage-gap dial. Critical or High severity audit findings that Vortex IQ surfaced more than 7 days ago and that still don’t have a Jira ticket attached. Every row is unambiguously bad: a known revenue-impacting issue that the engineering team has not yet been told about. Either the auto-dispatch failed (token expired, rate-limited, project misconfigured) or the merchant explicitly disabled it for that finding class.
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 fashion brand on Adobe Commerce, around £8M GMV/year, with Vortex IQ connected for 14 weeks and a 5-engineer team using Jira Cloud. Reading taken at 14:00 GMT on 18 Mar 26. The card displays 3 rows, the alert at>0 is firing.
What this tells the merchant:
- Two of three are dispatch failures from a single root cause. A 9-day-expired Atlassian token suppressed dispatch for everything filed after 08 Mar. Atlassian Token Expiry Imminent should have alerted 7 days before expiry, check whether the alert was muted or the email-routing was misconfigured. Rotate the token now and the back-pressure will dispatch 12 to 20 queued findings within 5 minutes.
- FND-2418 is the priority read. The Apple Pay regression on iOS 17.4 typically costs 4 to 8 percent of mobile checkout revenue at this AOV; 9 days of unmitigated impact at this brand’s £22k/day mobile revenue is roughly £8k to £16k of lost contribution. Manually file the ticket now, then trace why no engineer noticed the customer-service ticket spike that should have followed.
- FND-2502 is the legitimate suppression case. The previous CTO disabled dispatch for robots.txt findings because the brand had an unrelated long-running migration project that involved frequent robots.txt churn. Six months on, the migration is done, the suppression should be lifted. Open Vortex IQ → Settings → Connectors → Jira → Dispatch Rules and re-enable robots.txt auto-dispatch.
- The card stays at zero in healthy operation. A non-zero reading should NEVER persist beyond a single business day; this card is a tripwire, not a backlog. Treat it like a SEV-2 incident and drain to zero.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Jira’s own dashboard: This card is not visible inside Jira at all, by definition. It counts findings that have no ticket, so there is no Jira filter that can return them. The reconciliation surface is on the Vortex IQ side:
Open Vortex IQ → Audit → Findings → filter severity in (critical,high) AND age > 7d AND ticket_status = unfiled.
That filter returns the same row set the card displays. To verify the negative (that no ticket exists), copy any Finding ID from the list and search for it in Jira:
Cross-connector reconciliation:
Known limitations / merchant FAQs
The card just lit up with 4 rows. What’s the playbook? Five-minute triage. (1) Open Atlassian Token Expiry Imminent and Rate-Limit Exhausted, if either is firing, fix that first and the back-pressure will dispatch the queue automatically. (2) If neither is firing, open Vortex IQ → Settings → Connectors → Jira → Dispatch Rules, check whether someone disabled auto-dispatch for this severity tier in the last 14 days. (3) If dispatch rules look correct, open the Jira project and verify the API user still hasCreate Issues permission, a permission-scheme tightening is a common silent-failure root cause. (4) If everything looks correct, manually file the missing tickets from the Vortex IQ audit-finding page using the File to Jira button. (5) Once dispatched, the card returns to zero within 60 seconds.
A row has been on this card for 3 days. Is that bad?
Yes. The card’s job is to surface coverage gaps; a row that persists more than a single business day means the merchant has not actioned the alert. Either re-enable dispatch (the engineering team should know about this), file the ticket manually, or formally suppress it via the Accept risk button in the audit-finding detail page (which records the decision and stops the card surfacing it).
Why is the threshold 7 days and not 1 day?
Because findings less than 7 days old that have no ticket are still in the normal dispatch window. A 24-hour rate-limit recovery, a planned weekend token-rotation, a scheduled project migration, all legitimately delay dispatch by a day or two. The 7-day grace prevents this card from firing on transient operational events. Beyond 7 days, dispatch demonstrably failed, and human intervention is required.
Can I suppress a specific finding from this card without filing it?
Yes. Each row has an Accept risk button that records the merchant decision (with reviewer name, date, and reason) and removes the row. Suppressed findings reappear if the audit signature recurs after a fresh detection cycle, this is intentional, an accepted-risk position should be revisited periodically rather than buried.
Does this card double-count findings that are duplicates of each other?
No. Vortex IQ deduplicates audit findings by signature hash before filing, so a single underlying issue (e.g. “Apple Pay broken on iOS 17.4”) shows as one row, regardless of how many pages it was detected on. The detection page count is in the finding detail.
Why don’t Medium and Low findings show up here?
Volume. A typical Vortex IQ audit on an active merchant produces 30 to 60 Medium / Low findings per week. Auto-dispatching all of them would overwhelm a team’s queue; merchants opt-in to lower-tier dispatch under Settings → Connectors → Jira → Dispatch Rules. The Critical / High tiers are the auto-dispatch default because their merchant impact is unambiguous.
The card shows zero but customer-service tickets are spiking. Is the audit engine missing something?
Possibly. The audit engine has a fixed set of detection signatures; novel issues (e.g. a niche payment-provider regression specific to one EU country) may not have a Vortex IQ rule yet. Check Operational Health Score (Datadog) and GA4 Property Health for orthogonal signals. If something is moving in CS volume but no monitoring or audit signal sees it, the issue may be browser-only or geo-specific, escalate to manual triage.
How fast should I expect a row to disappear after I fix dispatch?
60 to 120 seconds for the next polling cycle, plus 5 to 30 seconds for Atlassian to confirm ticket creation. The card’s update is real-time; rows vanish as tickets are created. If a row persists more than 5 minutes after dispatch is restored, check the Jira API response in the Vortex IQ webhook log, a 4xx error means there’s a deeper config issue (project key changed, custom field renamed, etc).
My team uses GitHub Issues, not Jira. Can I make this card track GitHub Issues coverage instead?
Yes, when the GitHub connector is also configured for Vortex IQ Findings dispatch (not just code-changes). Configure in Settings → Connectors → GitHub → Dispatch Rules, then this card switches to a Critical Findings Without a GitHub Issue equivalent. Multi-tracker dispatch (file in both Jira and GitHub) is supported; coverage is then “missing in either” and the card flags both gaps.