> ## 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. # VortexIQ Findings Open, Jira > Tickets we filed from audit findings that haven't been resolved yet, the live backlog of things VortexIQ surfaced. How to read it, why it matters, and how... **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Project Management](/nerve-centre/connectors#connectors-by-type) > 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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/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** | The card reads **25 open** at this snapshot, the alert at `>20 open` is tripped (warn). What this tells the merchant: 1. **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)](/nerve-centre/kpi-cards/jira/abandoned-findings) to identify which ones are stalled. 2. **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_rate`](/nerve-centre/shopify/checkout_failure_rate) cross-correlation); one is a missing `hreflang` block on the `/de` locale that's costing organic German traffic. **Open the ticket detail page to triage; do not let critical findings wait for sprint planning.** 3. **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. 4. **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. Compare against the same merchant's reading **6 weeks ago** when they first connected: 41 open. The drain rate (41 → 25 across 6 weeks) is the team taking the audit seriously and burning down. If this number had stayed flat or grown, that would be the story for the founder. ## Sibling cards merchants should reference together | Card | Why pair it with VortexIQ Findings Open | What the combination tells you | | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | [VortexIQ Findings In Progress](/nerve-centre/kpi-cards/jira/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)](/nerve-centre/kpi-cards/jira/vortexiq-findings-resolved) | 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)](/nerve-centre/kpi-cards/jira/abandoned-findings) | 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)](/nerve-centre/kpi-cards/jira/finding-resolution-rate) | 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)](/nerve-centre/kpi-cards/jira/avg-time-to-fix) | 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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/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](/nerve-centre/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: ```jql theme={null} "Vortex IQ Finding ID" IS NOT EMPTY AND statusCategory != Done ``` > 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](/nerve-centre/kpi-cards/jira/oldest-open) to spot stale archives. | **Cross-connector reconciliation:** | Card | Expected relationship | Causes of legitimate divergence | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`audit_finding` registry inside Vortex IQ](/nerve-centre/INDEX) | 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`](/nerve-centre/kpi-cards/datadog/active-incidents) | 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`](/nerve-centre/newrelic/nr_alert_active_count) | Independent peer to Datadog incidents. | Same as above, alternative monitoring stack. | | [`shopify.checkout_failure_rate`](/nerve-centre/shopify/checkout_failure_rate), [`bigcommerce.bc_cart_abandonment`](/nerve-centre/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)](/nerve-centre/kpi-cards/jira/finding-resolution-rate) 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 uses `statusCategory != 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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/datadog/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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/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. *** ### Tracked live in Vortex IQ Nerve Centre *VortexIQ Findings Open* 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.