Findings sat in the backlog with no status change for two weeks, these are the ones losing money silently.
At a glance
Open Vortex IQ-tagged Jira issues with no field change in 14+ days. Jira is the dominant engineering-side PM tool for ecommerce merchants with dedicated engineering teams; the abandoned bucket here represents engineering-team-owned findings stuck in the backlog. On Jira-using merchants this card is the operational-discipline trip-wire; the parallel vortexiq_findings_open card sizes the queue, this card detects whether the queue is healthy.
| What it counts | Open Jira issues where labels contains vortex_iq_finding AND resolution IS EMPTY AND updated < -14d. JQL form: labels = "vortex_iq_finding" AND resolution = EMPTY AND updated < -14d. |
| What counts as movement | Any of: status transition, assignee change, priority change, fix-version change, comment added, custom-field edit, sub-task added, attachment added, link added. Jira tracks updated on any issue-level field change. |
| Project / board scope | All Jira projects in the connected workspace where the connector token has READ_ISSUE permission, intersected with projects tagged vortex_iq_outbound in connector setup. Most merchants connect a single project (typically called “Engineering” or “Vortex IQ Findings”). |
| Status filter | resolution IS EMPTY (i.e. unresolved, regardless of status). Issues moved through workflow but not yet Done / Won't Fix / Cannot Reproduce (which set the resolution field) still count. |
| Issue type filter | All issue types included (Bug, Story, Task, Epic, custom types). The category sub-labels (vortex_iq:checkout, vortex_iq:catalogue) do not filter. |
| Resolution counts | Done, Won't Fix, Cannot Reproduce, Duplicate all set the resolution field and remove the issue from this card. The card does NOT distinguish between them. |
| API endpoint | POST /rest/api/3/search/jql (Jira Cloud) or GET /rest/api/2/search (Server / Data Center) with the JQL above. Cursor-based pagination via nextPageToken. Vortex IQ batches at 100 issues per page; large backlogs may take 30 seconds to refresh. |
| Time window | RT |
| Alert trigger | >5 warn, >15 critical. Engineering-led teams using Jira often tune to >10 warn because Jira backlogs are typically larger than CX-tool backlogs. |
| Sentiment key | vortexiq_findings_abandoned (threshold-based, {warn: 5, critical: 15}). |
| Time zone | Jira’s updated is stored as UTC; the 14-day cutoff aligns to UTC. Multi-region merchants see consistent boundaries. |
| Atlassian Intelligence (AI) interaction | Atlassian’s AI assist can suggest summaries, status changes, and assignees. Accepted suggestions count as movement (issue field changes). Suggestions left unaccepted do NOT count. |
| 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 30-person ecommerce engineering team using Jira Software Cloud Premium. Single Jira site with three projects connected (ENG for engineering, OPS for operations, MKT for marketing tech). Snapshot taken on 02 May 26 at 11:20 BST.
| Jira project | Open Vortex IQ findings | Abandoned (>14d no movement) | Notes |
|---|---|---|---|
| ENG (engineering) | 22 | 8 | Six post-release findings from 18 Apr; two infra findings owned by the on-call rotation but unassigned individually. |
| OPS (operations) | 11 | 3 | Returns-policy and refund-flow findings; assigned to a single ops lead on PTO. |
| MKT (marketing tech) | 6 | 1 | Klaviyo-flow finding; awaiting marketing-team prioritisation. |
| Total open | 39 | 12 | At warn (>5), close to critical (>15). |
- The ENG project has 8 abandoned findings, the largest cluster. Six are post-release debt from the 18 Apr release; the team shipped, moved to the next sprint, never came back to the audit-flagged regressions. The classic engineering-led abandonment pattern.
- The two ENG infra findings owned by the on-call rotation but unassigned individually. Jira’s “owner = team” without a single assignee is the silent-leak design pattern; nobody owns it personally so nobody picks it up. Fix: add a Jira automation rule that assigns rotation-owned findings to the current on-call individual via the Atlassian Opsgenie integration.
- The OPS project’s 3 abandoned findings have a single root cause. All three sit on a single ops lead on PTO. The fix is reassignment, not hiring. Open Jira’s Issues, Group by Assignee and confirm.
- The MKT marketing-team finding is normal latency, not abandonment. Marketing-team findings often wait for sprint planning at the start of each sprint cycle; the 14-day clock crosses sprint boundaries on slower-cadence teams. Tune the threshold for marketing-team subprojects to 21 days if this becomes a recurring pattern.
- The Returns-policy and refund-flow findings on OPS are highest-revenue-risk. Returns-policy mismatches are conversion killers; refund-flow regressions drive both refund rate and customer-service load. Triage these first regardless of count.
- Use Jira Automation to auto-flag abandoned findings. Build a rule:
Trigger: scheduled (daily at 09:00) IF (labels CONTAINS 'vortex_iq_finding' AND resolution = EMPTY AND updated < -14d) THEN add comment '@assignee This finding has not moved in 14+ days. Triage today or mark Won't Fix.' AND apply label 'abandoned'. Most engineering teams who adopt this see abandoned-bucket size drop 40 to 60% within a month.
Sibling cards merchants should reference together
| Card | Why pair it with Abandoned Findings | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | Abandoned is a subset of open. The ratio is the steadier read. | Abandoned ÷ Open above 25% on Jira = the queue is stagnating. |
| Finding Resolution Rate (90d) | Resolution rate drops first; abandoned count rises second. | The textbook capacity-collapse sequence. |
| Avg Time-to-Fix (days) | Cycle-time peer. | Time-to-fix rising AND abandoned rising = team starting then stalling, not refusing the work. |
| Sprint Velocity | Velocity drops are the leading indicator of abandonment. | Velocity flat + abandoned rising = findings being filed but never planned in. |
| Issues by Assignee | Where abandonment concentrates. | If 70% of abandoned findings sit on one assignee, the fix is reassignment, not hiring. |
| Overdue Issues | Subset of abandoned with a due-date breach. | Overdue + abandoned = formally late and silently leaking; highest-priority fixes. |
| Datadog Health Score | Independent peer. | Both elevated = engineering firefighting + audit work falling behind. |
| Shopify / BigCommerce Refund Rate | Downstream cost metric. | Abandoned on returns/checkout findings drives refund rate up over a 4 to 8 week trailing window. |
| Customer Service Sentiment | NPS-side outcome. | Sustained abandoned predicts CSAT drop within a quarter. |
Reconciling against the vendor’s own dashboard
Where to look in Jira’s own dashboard:
Jira Issue Search with JQL: labels = "vortex_iq_finding" AND resolution = EMPTY AND updated < -14d ORDER BY updated ASC. Save as a filter via Save as; pin it to the team’s Jira dashboard.
Jira Dashboard build a gadget showing the saved filter’s count; the team sees the abandoned bucket inline with their normal Jira rhythm.
Atlassian Analytics (Premium / Enterprise tier) can build a chart of abandoned-bucket size over time using the same JQL.
Why our number may legitimately differ from the saved Jira filter:
| Reason | Direction | Why |
|---|---|---|
| Time zone | None expected | Both Jira and the card use UTC for the updated timestamp comparison; gap is rare. |
| Resolution-field semantics | Either | The card uses resolution IS EMPTY. Some teams transition issues to a Done status without setting the resolution field (a workflow misconfiguration); these issues stay in the card’s count even though the kanban-trained eye assumes “in the Done column = closed”. Audit Jira workflow if status and resolution drift apart. |
| Cross-project aggregation | Either | Card aggregates across vortex_iq_outbound projects; Jira’s saved filter is whatever JQL scope you set. Match the JQL project IN (ENG, OPS, MKT) to align. |
| Permission scope | Ours can be lower | The connector token has specific project-read permissions; if a project was added after connector setup without re-granting permission, the card may miss it. |
| Atlassian AI movement | Same in both | Atlassian Intelligence accepted suggestions update updated, and both the card and JQL respect this. Unaccepted suggestions do not update updated. |
| Webhook delay | Up to 60s stale | Jira’s webhook delivery typically arrives within 5 seconds; high-volume sites can see up to 60 seconds. |
| API rate-limit on large backlogs | Up to 30s stale | Jira Cloud rate-limits search at 100/min for free tier and 500/min for Standard+; the card batches at 100/page. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
datadog.dd_incidents_active | Independent. Datadog tracks live engineering incidents (server-side); Jira tracks the planned remediation work (audit-side). | Both elevated = engineering firefighting + audit work piling up. |
newrelic.nr_open_incidents | Same shape as Datadog comparison. | Same reasoning. |
shopify.refund_rate | Inverse correlation; abandoned findings on refund-flow / checkout drive refund rate over a 4 to 8 week window. | Abandoned on returns / checkout = refund rate climbs; abandoned on cosmetic findings only = no refund correlation. |
Known limitations / merchant FAQs
My Jira filter says I have 14 abandoned but the card says 12. Which is right? Almost always one of these. (1) Cross-project scope: the card aggregates across allvortex_iq_outbound projects; your filter may scope to one. (2) Resolution-field semantics: the card requires resolution IS EMPTY; if your filter uses status names directly (e.g. status NOT IN (Done, "Won't Fix")) and a workflow misconfiguration lets a status reach Done without setting the resolution field, your filter and the card diverge. (3) Webhook delay or API rate-limit lag during peak hours.
A Jira issue is in the “Done” column but my abandoned card still counts it. Why?
Workflow misconfiguration. The “Done” column on a kanban board is a visual grouping; what closes an issue from JQL’s perspective is the resolution field being non-empty. If your workflow lets a status reach the Done column without setting the resolution field, the issue is logically still unresolved. Audit Project Settings, Workflows; ensure every status that lands in the Done column has a transition that sets resolution. Atlassian’s documentation calls this the “Done resolution gap” and it is the most common cause of inflated abandoned counts.
What counts as movement?
Any of: status transition, assignee change, priority change, fix-version change, comment added, custom-field edit, sub-task added, attachment added, link added. Renaming the issue or editing the description also counts. Atlassian Intelligence accepted suggestions count (they update updated); unaccepted suggestions do not.
The 14-day window feels arbitrary. Can we tune it?
Yes, in Settings, Connectors, Jira, Abandonment threshold (days). Default is 14 days. Engineering teams running 2-week sprints often tune this down to 7 days because their cycle time is faster; teams running 4-week sprints tune up to 21 days because their planning cadence is slower.
We have multiple Jira projects connected. The count looks alarming.
Open the per-project stack panel from the connector drawer to see which project drives the abandoned count. Most multi-project merchants find the abandoned bucket concentrates in one or two projects (typically the lowest-priority project that gets de-prioritised under sprint pressure).
Velocity dropped, abandoned count rising. What changed?
Standard playbook. (1) Open Sprint Velocity; if velocity dropped, the team is being interrupted or under-staffed. (2) Open Issues by Assignee for sudden concentration changes; a key person on PTO is the most common cause. (3) Cross-check Datadog incidents; a sustained incident burst pulls the team off audit work for days. (4) Check whether sprint planning includes Vortex IQ findings; if findings are routinely deferred to “next sprint”, they accumulate.
The abandoned count appears suddenly higher overnight. Why?
Because the 14-day clock keeps ticking. If five findings were last touched on the same day exactly 14 days ago, all five become abandoned at the same time the next day. Normal and self-corrects within 24 hours of the team picking the queue back up.
Should I close abandoned findings or fix them?
Both, depending on triage. Run a weekly 30-minute “abandoned review” with one engineering lead. For each: if no real merchant impact, transition to Won't Fix with a comment explaining why. If real merchant impact, reassign and add to next sprint. We see Jira-using teams close 30 to 50% of abandoned findings on this triage as Won't Fix (out-of-scope, duplicate, no-longer-relevant); the remainder being correctly prioritised into a sprint is the win.
Can Jira Automation auto-flag or auto-close abandoned findings?
Yes. (1) Auto-flag: build a rule that comments @assignee This finding has not moved in 14+ days. Triage today or mark Won't Fix. on any matching issue, daily at 09:00. (2) Auto-close low-impact: build a rule that transitions any matching issue with priority Low or Lowest to Won't Fix after 21 days no-movement, with a comment explaining the auto-close. Most engineering teams who adopt these rules see abandoned-bucket size drop 40 to 60% within a month with no manual triage.
Why doesn’t Jira ship an “abandoned” filter natively?
Jira ships the JQL primitives (updated < -14d, labels CONTAINS X, resolution = EMPTY) but not the curated view. The card’s added value: cross-project aggregation, threshold-based alerts, historical trend, and cross-connector reconciliation. Engineering teams comfortable with JQL can build the saved filter themselves.
A finding important enough to fix manually but we never used Jira to track it. Do we close the ticket?
Yes. Transition the issue to Done (with a Done resolution) once the work is shipped, or Won't Fix if the audit signal is no longer relevant. Otherwise it stays in the abandoned bucket. Vortex IQ does not auto-close findings just because the underlying audit signal cleared; the human acknowledgement is the close signal.
Can Atlassian Intelligence help me clear the abandoned bucket?
Partially. AI can suggest summaries, status changes, and assignees on individual issues; accepted suggestions count as movement and reset the abandonment clock. AI cannot triage the bucket as a whole. The combination that works: open the saved abandoned filter, walk through 5 to 10 issues, accept AI suggestions where reasonable, manually triage the rest. Reduces a 30-minute weekly review to 10 to 15 minutes.
Multi-site Jira: my company has US and EU Jira sites. Does the card aggregate?
Yes by default if both are connected. Multi-site is rare; most ecommerce merchants run one Jira site with multiple projects. If your sites are genuinely separate (e.g. acquired company kept its own Jira), configure two connectors for per-site cards.
Is this card the right primary watch metric for Jira-using merchants?
Yes. Findings Open tells you the queue size; this card tells you the queue health. Both are hero cards because they answer different questions. On engineering-led merchants using Jira, the abandoned card is the single best signal of audit-programme health because Jira backlogs naturally grow over time; the abandoned subset is what flags execution-discipline regressions.