Findings sat in the backlog with no status change for two weeks, these are the ones losing money silently.
At a glance
The number of open Linear issues withvortex-iq-findinglabel whoseupdatedAthas not changed in 14+ days. On Linear this card carries unusual weight because Linear teams rarely accumulate stale work by accident; the cycle model and engineer-led culture push completion. A rising count is a stronger signal here than on Asana, ClickUp, or Monday: it means the cycle discipline is breaking down.
| What it counts | Linear issues labelled vortex-iq-finding with state.type ∈ {triage, backlog, unstarted, started} AND updatedAt older than 14 days. The 14-day window is fixed by default; tunable per organization. |
| API endpoint | Linear GraphQL issues(filter: {labels: {name: {eq: "vortex-iq-finding"}}, state: {type: {nin: [completed, canceled]}}, updatedAt: {lt: "<now-14d>"}}). Linear’s GraphQL filter supports updatedAt directly, no client-side filtering needed. |
| What counts as “movement” | Any of: state change, assignee change, priority change, estimate change, label change, cycle assignment change, comment posted, description edit, title edit. Linear updates updatedAt on any of these. What does NOT count: viewing the issue, watching/unwatching, time-tracking entries (Linear surfaces these via subscriptions, not as edits). |
| Closed issues excluded | Yes. The moment an issue moves to completed or canceled state, Linear’s webhook fires and the issue drops from this count. |
| Workspace scope | All Linear teams in the connected workspace tagged vortex_iq_outbound. |
| Time window | RT. The 14-day staleness clock is rolling, evaluated on every webhook event. |
| Alert trigger | > 5 (warn), > 15 (critical). Engineering teams using Linear typically sit at 0-3; anything above 5 is the signal. |
| Sentiment | Threshold-based, {warn: 5, critical: 15}. |
| Time zone | updatedAt is ISO-8601 UTC. The 14-day cutoff is applied in UTC. |
| Multi-team aggregation | Yes; per-team stack panel available. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Linear 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 US home-fitness brand on Shopify Plus with an 8-engineer team running Linear on weekly cycles. Snapshot taken on 02 May 26 at 11:30 EDT.| Linear team | Open | Abandoned (>14d no movement) | Notes |
|---|---|---|---|
| ENG (engineering) | 12 | 4 | Three findings dropped to Backlog during a hot incident two weeks ago and never picked back up. One in Triage since the team lead went on parental leave. |
| INFRA (site-reliability) | 6 | 2 | Two CDN-cache findings deferred pending a vendor decision that has not landed. |
| Total open | 18 | 6 | Warn threshold crossed. |
- 6 stale issues on a Linear team is a meaningful signal. Engineering teams on Linear typically sit at 0-3 abandoned because the cycle model surfaces drift fast. Crossing warn means the cycle discipline broke at least once in the last fortnight.
- The ENG cluster has a clear root cause: an incident pulled the team off audit work. This is the single most common Linear abandoned-rate driver. Pair this card with Datadog incidents, if Datadog showed a sustained incident burst 2-3 weeks ago, this is the operational fallout.
- The Triage entry on parental leave is the single-point-of-failure marker. Triage means “no one has decided who owns this”; with the team lead away, no one is taking the decision. The right action is to reassign Triage ownership to a deputy for the leave duration.
- The INFRA vendor-pending cluster is debatable. Some teams prefer to mark vendor-blocked work as
canceled(closing the loop on Linear’s side, with a comment to re-create when the vendor returns). Others prefer to leave it open as a reminder. Either is defensible; what is not defensible is leaving it open and ignoring the abandoned signal. - The right action is a 15-minute cycle-retro audit. On a Linear team this is what stops staleness compounding. End-of-cycle review of any issue with
updatedAtolder than the cycle length: complete, cancel, or explicitly carry forward with an updated estimate. Linear’s keyboard shortcuts make this fast.
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. | Abandoned ÷ Open above 25% on a Linear team is a louder signal than the same ratio elsewhere; the platform usually self-corrects. |
| Finding Resolution Rate (90d) | Resolution rate drops first, abandoned rises second. | Resolution falling for two cycles then abandoned spiking is the textbook capacity-collapse sequence on Linear. |
| Avg Time-to-Fix (days) | Distinguishes “slow but moving” from “abandoned”. | Time-to-fix rising AND abandoned rising = team is starting then stalling, not refusing the work. |
| Tickets by Assignee | Whether abandonment concentrates on one engineer. | A single engineer with several stale items is the leave/holiday/incident pattern. |
| Cycle Progress | Whether stale issues sit inside a cycle or float in backlog. | Stale issues outside any cycle are the most common abandoned shape on Linear. |
| Cycle Velocity (avg) | Capacity ceiling. | Abandoned rising while velocity holds = audit work being deprioritised against feature work. |
| Scope Added Mid-Cycle | Mid-cycle scope additions push audit work to the back. | High scope creep + rising abandoned = team is reactive, not proactive. |
Reconciling against the vendor’s own dashboard
Where to look in Linear’s own UI:linear.app then for each connected team open Issues. Apply filters:For multi-team visibility, the Workspace → Issues view (Enterprise plan) lets you apply the same filter across all teams. Why our number may legitimately differ from a saved Linear filter:Label is "vortex-iq-finding",State is not Completed and not Cancelled,Updated is more than 14 days ago. Save the view as Stale Findings withcmd+s. Linear’s filter for “Updated” is named-relative-time aware, so the filter automatically rolls forward as time passes.
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary day off | Linear’s UI uses your account-profile timezone for “more than 14 days ago”; we apply the cutoff in UTC. |
| State-type interpretation | Same in most cases | Both we and the saved filter exclude completed and canceled. |
| Auto-archive | Same | Linear’s auto-archive of completed issues kicks in well after the 14-day window, so it does not affect this card. |
| Label spelling | Ours scoped | We read the label vortex-iq-finding exactly. |
| Multi-team aggregation | Ours wider | Linear’s Issues view scopes to one team by default; we sum. |
| Webhook delay | Ours up to 5s stale | Linear’s webhooks are very fast. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
datadog.dd_incidents_active | Often correlated. A Datadog incident burst pulls the engineering team off audit work; Linear abandoned-rate climbs 1-2 weeks later. | A Datadog incident closed without a Linear follow-up issue may indicate the underlying cause is unaddressed. |
newrelic.nr_open_incidents | Same shape. | Same reasoning. |
Known limitations / merchant FAQs
Linear shows my issue was edited yesterday but you say it’s abandoned. What’s wrong? Almost always the timezone or webhook delay. Linear’s UI shows “edited yesterday” in your account-profile timezone; our 14-day cutoff is UTC. For a boundary-day issue, the calendar day differs. Refresh in 30 seconds; the gap is very rare on Linear because webhooks are fast. What counts as movement? Any of: state change, assignee change, priority change, estimate change, label change, cycle assignment change, comment posted, description edit, title edit. Linear bumpsupdatedAt on each. What does NOT count: viewing the issue, watching/unwatching, time-tracking entries.
The 14-day window feels long for Linear. Can we tune it down?
Yes. Engineering teams running weekly cycles often tune to 7 days because the cycle length is the natural staleness boundary. Settings → Connectors → Linear → Abandonment threshold (days). Some teams set it to the cycle length plus a buffer (e.g. 2-week cycle → 16-day threshold).
A finding is in Triage and has been there 16 days. That feels intentional, why count it?
Because Triage is meant to be transient (under 24 hours typically). 16 days in Triage is the inverse signal: nobody is reviewing the Triage queue. The right action is to assign Triage ownership; the cleanest fix is Settings → Triage → Triage owner.
We use multiple Linear teams. The count looks alarming.
Open the per-team stack panel; on Linear the staleness usually concentrates on one team that just had a leave/incident/transition.
Resolution rate dropped, abandoned rising. What changed?
Standard playbook: (1) Datadog/New Relic incidents in the last 2-3 weeks. Engineering-led teams on Linear are the most incident-correlated of any PM tool we connect to. (2) Tickets by Assignee for sudden concentration changes. (3) Cycle Progress for whether findings are entering cycles at all.
The abandoned count appears suddenly higher overnight. Why?
The 14-day clock keeps ticking even when no one is editing. If 5 issues were last touched on the same day exactly 14 days ago, all 5 become abandoned at the same time the next day. Self-corrects within 24 hours of the team picking the queue back up.
Should I close abandoned issues or fix them?
Both, depending on triage. On Linear specifically the cleanest path is the end-of-cycle retro: any issue with updatedAt older than the cycle length gets a decision (complete, cancel, or carry forward with updated estimate). Most Linear teams find 30-50% of stale items should be cancelled, the cycle discipline does most of the work for them.
Is this the right card for my context, or should I focus on Findings Open?
On Linear specifically this card is the queue-health indicator; Findings Open is queue size. The platform usually self-corrects open count via cycles, so abandoned is the louder signal when something is genuinely off.
Why doesn’t Linear ship a built-in “abandoned” view?
Linear’s product philosophy holds that cycles are the staleness primitive: any issue not completed in its cycle is by definition stale. The 14-day overlay this card adds is finer-grained than Linear’s native cycle boundary, useful for teams that mix sprints with always-on work.