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.
| What it counts | audit_finding WHERE severity IN ('critical','high') AND created_at < NOW() - 7 days AND id NOT IN (SELECT vortexiqFindingId FROM jira.tracker_item). A pure left-anti-join between the Vortex IQ audit-finding table and the Jira tracker-item table. |
| Why 7 days? | The 7-day grace lets the engineering team complete a normal sprint cadence before we flag a coverage gap. Findings less than 7 days old that have no ticket are still in the normal dispatch window; older than 7 days means dispatch demonstrably failed or was suppressed. |
| Severity scope | Critical and High only. Medium and Low findings are excluded from this card because dispatching them all into Jira would overwhelm a typical team’s queue; merchants opt-in per severity tier. The Critical / High tiers are auto-dispatched by default. |
| Auto-dispatch failure modes | (1) Atlassian API token expired, see Atlassian Token Expiry Imminent. (2) Atlassian rate-limited the bulk-create, see Rate-Limit Exhausted. (3) Custom field mapping broke after a Jira admin renamed Vortex IQ Finding ID. (4) The Jira project chosen at setup was archived. (5) Project permission scheme tightened to exclude the API user. |
| Merchant-suppress modes | The merchant explicitly disabled auto-dispatch for that finding class in Vortex IQ → Settings → Connectors → Jira → Dispatch Rules. This is legitimate (e.g. a known accepted technical-debt position) but should be reviewed periodically; this card surfaces every suppression so it never silently rots. |
| Merchant impact | Each row is a currently un-tracked, un-triaged, currently-shipping-to-customers issue. A Critical finding here can be costing the merchant 1 to 5 percent of revenue per day; a High finding 0.2 to 1 percent. The card label “money on fire” is accurate, not rhetorical. |
| Refresh cadence | Real-time. Recomputed every 60 seconds against the audit-finding and Jira-tracker-item tables. |
| Time window | RT (live count, no period boundary). |
| Alert trigger | >0. Any non-zero reading is a coverage-gap alert and should never persist beyond the time it takes the merchant to either re-enable dispatch or manually file the ticket. |
| 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 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.
| Finding ID | Severity | Detected | Title | Why no ticket? |
|---|---|---|---|---|
| FND-2418 | Critical | 09 Mar 26 | Apple Pay button missing on iOS 17.4+ checkout | Token expired 08 Mar 26 at 23:47 UTC; auto-dispatch silent for 9 days |
| FND-2431 | High | 11 Mar 26 | hreflang block missing on /de and /fr locales | Same expired token, same dispatch outage |
| FND-2502 | High | 14 Mar 26 | Robots.txt blocks /checkout/cart from Googlebot | Auto-dispatch re-enabled 12 Mar 26, but this finding’s dispatch rule was set to “manual review” by the previous CTO |
- 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
| Card | Why pair it with Critical Findings Without a Jira Ticket | What the combination tells you |
|---|---|---|
| Finding-to-Ticket Dispatch Lag | The latency-side companion. | Lag rising for 24h then this card going non-zero is the leading-then-lagging pair, dispatch is degrading and now demonstrably failing. |
| Atlassian Token Expiry Imminent | The most common root cause. | If the token-expiry alert fires AND this card lights up, those are the same incident, fix the token first. |
| Rate-Limit Exhausted | The second-most-common root cause. | If both fire, Atlassian is throttling bulk-create; back off the dispatch rate, do not re-trigger. |
| API Rate-Limit Headroom | The leading indicator of throttling. | Headroom < 20% predicts this card going non-zero within 1 to 6 hours during heavy audit cycles. |
| VortexIQ Findings Open | The complement set, filed findings still open. | This card growing while Open shrinks means the team is draining the visible queue while critical issues bypass it entirely, the worst possible shape. |
| Avg Time-to-Fix | Speed of the drain when tickets do exist. | High time-to-fix and a non-zero reading here means even when findings reach the team, throughput cannot keep pace. |
| Cross-connector: Datadog Active Incidents | Operational-side parallel. | An open SEV-1 in Datadog and a Critical-no-ticket in Vortex IQ on the same service is one merchant problem, not two. |
| Cross-connector: Shopify Checkout Failure Rate, BigCommerce Cart Abandonment, Adobe Commerce Order Failure | The merchant-impact metric these un-ticketed findings often drive. | If checkout failure is up while this card is non-zero, you have a quantifiable revenue cost for the dispatch outage. |
| Cross-connector: GA4 Property Health | Browser-side measurement-health peer. | Both red equals an active multi-system incident; one red means investigate the source. |
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:
| Reason | Direction | Why |
|---|---|---|
| Recently re-enabled dispatch | Ours higher briefly | After a token rotation or rate-limit recovery, queued findings dispatch in batches; the card may show 5 or 6 rows that vanish within 60 to 120 seconds as the back-pressure drains. |
| Custom field renamed | Ours overstated permanently | If a Jira admin renamed the Vortex IQ Finding ID custom field, the left-anti-join cannot match existing tickets to findings; everything looks un-ticketed. Fix in config/vortex_mind/manifests/jira.yaml. |
| Project archived | Ours overstated | Archived Jira projects don’t return tracker-items in the API by default; tickets that exist but live in an archived project show up here as “no ticket”. Either un-archive or move tickets to a live project. |
| Permission scheme tightened | Ours overstated | If the API token’s user lost Browse Projects on the destination project, existing tickets become invisible to the join, replicating the “no ticket” pattern. |
| Manual filing in another tracker | Ours overstated for that finding | If the merchant manually filed in Linear, Asana, or GitHub Issues instead of Jira, Vortex IQ does not see it. Use the Mark as filed elsewhere override in the audit-finding detail page. |
| Severity reclassified mid-window | Ours under or over | If a finding was filed when severity was Medium and later promoted to High, the 7-day clock starts from the promotion date, not the original detection date. |
| Card | Expected relationship | Causes of legitimate divergence |
|---|---|---|
audit_finding registry | Sum of (open VortexIQ tickets) + (this card’s count) + (findings <7d old without tickets) should equal total open Critical+High audit findings. | Tickets in archived Jira projects, manually-filed-elsewhere overrides, permission-hidden tickets. |
datadog.dd_incidents_active | Operational SEV-1 parallel. | Different signal sources (Datadog watches metrics; Vortex IQ watches audit signatures). Both red equals same merchant problem with two unmitigated routes. |
shopify.checkout_failure_rate and platform peers | When this card lights up with a Critical revenue-impact finding, expect the corresponding commerce-side metric to be moving within hours. | Lag between technical regression and shopper abandonment varies by traffic volume and time of day. |
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.