Skip to main content
Card class: Hero • Category: Project Management
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 ClickUp tasks with vortexiq_finding_id whose date_updated is older than 14 days. ClickUp’s custom-status spectrum makes “stuck in review” patterns common: a task can sit in In Review, QA, or Awaiting Customer for weeks while looking active in the List view. This card cuts through that visual noise by reading the modification timestamp directly.
What it countsOpen tasks with vortexiq_finding_id set, archived = false, status.type ≠ 'closed', AND date_updated (Unix epoch ms) older than 14 days. The 14-day window is fixed by default; tunable per organization in connector settings.
API endpointGET /api/v2/list/{list_id}/task?archived=false&include_closed=false&order_by=updated&reverse=false&page=N from https://api.clickup.com/api/v2. We page until last_page = true and apply the 14-day staleness check client-side.
What counts as “movement”Any of: status change, assignee change (single or multi-assignee), due-date change, comment posted, custom-field edit, description edit, or completion. ClickUp updates date_updated on any of these. What does NOT count: a teammate viewing the task (ClickUp does not expose “viewed” events on the API surface), and time-tracking entries (which update a separate audit log but not date_updated).
Closed tasks excludedYes. The moment a task moves to a closed-type status, ClickUp’s webhook fires and the task drops out of the count.
Archived tasks / Lists / SpacesExcluded server-side.
Workspace scopeAll vortex_iq_outbound Lists across all Spaces in all connected Workspaces.
Time windowRT. The 14-day staleness clock is rolling, evaluated on every webhook event with a 5-minute reconciliation safety net.
Alert trigger> 5 (warn), > 15 (critical). ClickUp’s custom-status flexibility means “stuck in review” patterns are common, so the warn threshold catches them early.
SentimentThreshold-based, {warn: 5, critical: 15}.
Time zonedate_updated is Unix epoch ms (UTC). The 14-day cutoff is applied in UTC.
Multi-workspace aggregationYes by default; per-workspace stack panel available.
Rolesowner, operations

​
Calculation

Calculated automatically from your ClickUp 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-based mid-market apparel brand on BigCommerce, 32-person team. ClickUp is the all-in-one workspace; each functional team has its own Space with custom statuses tuned to its workflow. Snapshot taken on 02 May 26 at 09:45 EDT.
Space → ListCustom statusesOpenAbandoned (>14d no movement)Notes
Marketing → Campaign Ops”Open”, “In Review”, “In Progress”, “Done”184Four findings parked in In Review for 16-22 days while the marketing lead works on the next campaign.
Catalogue → Product Onboarding”To Do”, “Photography”, “Copywriting”, “QA”, “Live”126Six findings stuck at Copywriting since the freelance copywriter went off-contract; backlog visible to a new hire who has not started.
Engineering → Site Reliability”Backlog”, “In Sprint”, “Code Review”, “Released”91Healthy; engineering closes within sprint. The one stale item is a low-severity refactor that is being intentionally deferred.
CX → Tickets”New”, “Working”, “Awaiting Customer”, “Resolved”53Three findings stuck in Awaiting Customer for 17-25 days, customer response never returned.
Total open4414
Abandoned count        14
Warn threshold          5  (>5 warn)
Critical threshold     15  (>15 critical)
Status                 warn (between thresholds)
30D average abandoned   8
Delta vs 30D avg     +75%
What the merchant should read into this:
  1. Status sits at the upper end of warn, almost critical. 14 stale findings on a 32-person team is a meaningful queue-health regression. The pattern, custom-status purgatory, is the most common abandoned-rate driver on ClickUp.
  2. The Catalogue cluster has a single root cause, the off-contract copywriter. Six findings stuck at Copywriting is not a tooling problem; it is a staffing gap. Reassign or close.
  3. The Marketing In Review cluster is the textbook ClickUp anti-pattern. In Review is type custom, not closed, so we keep counting it open. If the team’s intent is “review by self-checkout”, the right move is to map In Review → closed type in Space Settings; if the intent is “review by another teammate”, the right move is to assign a reviewer at status-change time so the queue moves.
  4. The CX Awaiting Customer cluster is debatable. Some teams prefer to exclude this status because the team genuinely cannot progress these. If you agree, change Awaiting Customer to type closed in Space Settings → Statuses (this is reversible). The connector will automatically drop these from the abandoned count on the next 5-minute poll.
  5. Engineering’s 1 stale item is healthy. Engineering teams using ClickUp Sprints typically run cleaner because the sprint commitment forces decisions. If your engineering Space’s abandoned count climbs, check whether sprints are actually closing.

​
Sibling cards merchants should reference together

CardWhy pair it with Abandoned FindingsWhat the combination tells you
VortexIQ Findings OpenAbandoned is a subset of open. The ratio is the steadier read.Abandoned ÷ Open above 30% means a third of the queue has gone dormant; on ClickUp this is the most common indicator of custom-status purgatory.
Finding Resolution Rate (90d)Resolution rate drops first; abandoned count rises second.Resolution falling for two weeks then abandoned spiking is the textbook capacity-collapse sequence.
Avg Time-to-Fix (days)Distinguishes “slow but moving” from “abandoned”.Time-to-fix rising AND abandoned rising means the team is starting then stalling, not refusing the work.
Tickets by AssigneeTells you whether abandonment concentrates on one person. ClickUp’s multi-assignee model means a stale task can sit on three people; load is shared, blame is not.If most abandoned items share one assignee, the fix is reassignment.
Overloaded Assignees (>10 open)Same person often appears on both.An overloaded assignee with several abandoned items needs an immediate queue review.
Sprint ProgressClickUp Sprint folder commitment progress.Findings that never enter a sprint are the ones that abandon.
Scope Added Mid-SprintMid-sprint scope creep crowds out audit findings first.High scope creep + rising abandoned = the team is reactive, not proactive.

​
Reconciling against the vendor’s own dashboard

Where to look in ClickUp’s own UI:
app.clickup.com then for each vortex_iq_outbound List, switch to List view, click Filter, and add three filters: Custom Field → vortexiq_finding_id → has any value, Status → is not Closed, and Date updated → more than 14 days ago. ClickUp’s Dashboards module (Unlimited and above) supports a “Tasks by status” widget filtered the same way, with Group by → Custom Field to surface stale clusters. ClickUp also has a Workload view that shows time-since-last-update per task, which is closer to the visual experience of this card than the List filter.
ClickUp does not have a single “abandoned” filter, the closest is the saved-filter combination above. PMOs sometimes save it as a Workspace-level view named Stale Findings and use it as a weekly triage starting point. Why our number may legitimately differ from a saved ClickUp filter:
ReasonDirectionWhy
Time zoneBoundary day offClickUp’s UI uses your account-profile timezone for “more than 14 days ago” filters; we align the cutoff to UTC.
Status-type interpretationEitherWe treat status.type = 'closed' as resolved. If your saved filter uses Status is not Closed, that matches us. If your filter uses Status is not Closed AND not Done, the saved filter will be lower.
Subtask handlingOurs can be lowerA parent task with stale subtasks: ClickUp’s filter may include subtasks; we count only the parent because that’s where the vortexiq_finding_id lives by default.
Custom-field deletionOurs lowerIf vortexiq_finding_id was cleared on a stale task, the task drops out of our count even though it is still abandoned in operational reality.
Cross-workspace aggregationOurs widerWe sum across connected ClickUp Workspaces; a Dashboard widget is per-Workspace by default.
Webhook delay vs scheduled refreshOurs up to 60s staleMost edits arrive via webhook within seconds; the 5-minute reconciliation is the safety net, so our worst case is 60 seconds behind ClickUp.
Cross-connector reconciliation. ClickUp abandoned vs incident-management peers:
CardExpected relationshipWhat causes the divergence
datadog.dd_incidents_activeIndependent. A live Datadog incident is paging-grade engineering signal; an abandoned ClickUp finding is organisational-discipline signal.A growing Datadog count alongside a growing ClickUp abandoned count is the compound signal of engineering firefighting and ops falling behind simultaneously.
newrelic.nr_open_incidentsSame shape.Same reasoning.

​
Known limitations / merchant FAQs

ClickUp shows my task was edited yesterday but you say it’s abandoned. What’s wrong? Almost always one of two things. (1) The “edit” was a workspace-admin operation (e.g. someone restored a custom field, or a Space-Settings status rename touched the task’s date_updated); we read date_updated directly and these admin events do bump it. Open the task and check the activity stream, if there’s no human-action entry in the last 14 days, our count is correct. (2) Webhook + reconciliation lag: an edit made in the last 60 seconds may not have reached us yet; refresh in a minute. What counts as movement? Any of: status change, assignee change (single or multi), due-date change, comment posted, custom-field edit, description edit, or completion. Renaming the task or adding a checklist item also counts. What does NOT count: viewing the task, watching/unwatching it, time-tracking entries (these update a separate audit log), or status reorder operations at the Space level. The 14-day window feels arbitrary. Can we tune it? Yes, in Settings → Connectors → ClickUp → Abandonment threshold (days). We default to 14 days because it sits one full sprint plus a buffer. Engineering-led ClickUp Spaces (using Sprint folders) often tune this down to 7 days; agency-led Spaces with longer client cycles sometimes tune it up to 21 days. Marketing Spaces with custom statuses like In Review and Awaiting Customer sometimes prefer to map those statuses to type closed instead of widening the window. We have multiple ClickUp Workspaces. The count looks alarming. Open the per-workspace stack panel from the connector drawer to see which workspace is driving the count. ClickUp Enterprise customers sometimes have 5+ Workspaces (per-region or per-brand); the abandoned-rate cluster usually concentrates on one or two with specific staffing transitions. Custom statuses like “Awaiting Customer” or “Blocked”, should they count as abandoned? By default, yes, because the platform itself treats them as custom (not closed) status type. The cleanest fix is operational: change the status type to closed in Space Settings → Statuses if your team’s intent is “this is parked, the team has done its part”. This drops the task out of the abandoned count immediately and reflects the operational reality. The alternative (asking the connector to per-status-exclude) works but is less self-documenting. Resolution rate dropped, abandoned rising. What changed? Standard playbook: (1) Open Tickets by Assignee and look for sudden concentration changes; ClickUp’s multi-assignee model means a stale task can sit on three people, so look at the primary assignee column. (2) Open Sprint Progress; if velocity dropped because findings stopped entering sprints, the bottleneck is the Sprint planning, not the team. (3) Open Scope Added Mid-Sprint; ClickUp Sprints are easy to add to mid-cycle, scope creep is the second-most-common driver of abandoned items. (4) Cross-check against Datadog incidents for engineering-led Spaces. The abandoned count appears suddenly higher overnight, even though no one was working. Why? Because the 14-day clock keeps ticking even when no one is editing. If 5 tasks were last touched on the same day exactly 14 days ago, all 5 become abandoned at the same time the next day. This is normal and corrects itself within 24 hours of the team picking the queue back up. Should I close abandoned tasks or fix them? Both, depending on triage. Run a weekly 30-minute “abandoned review” with one ops lead per Space. For each: if no real merchant impact, move to a closed-type status (don’t just rename it; the type is what we read). If real merchant impact, reassign and put in next sprint. Most ClickUp teams find 30-50% of abandoned items should be closed-not-fixed. Is this the right card for my context, or should I focus on Findings Open? Findings Open tells you queue size; this card tells you queue health. On ClickUp specifically, this card is more important than on most other PM tools because the custom-status flexibility makes “stuck in review” patterns easy and visually invisible. If you only watch one ClickUp findings card, watch this one. Why doesn’t ClickUp ship a built-in “abandoned” view? ClickUp ships a flexible custom-status system instead, leaving “abandoned” as a question each team answers via filters. The same applies to Asana, Monday, Linear, Trello, and Basecamp; none of them ship an abandoned-task primitive, all of them have task-modification timestamps we can read. Time tracking touches the task often but the work hasn’t moved. Does that count? No. Time-tracking entries update a separate audit log but do not bump date_updated. This is correct: a teammate logging time on a task they have not actually progressed should not reset the staleness clock.

​
Tracked live in Vortex IQ Nerve Centre

Abandoned Findings (>14d no movement) is one of hundreds of KPI pulses Vortex IQ tracks across ClickUp 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 or book a demo to see this metric running on your own data.