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 withvortexiq_finding_idwhosedate_updatedis 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.
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.- 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.
- 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.
- The Marketing In Review cluster is the textbook ClickUp anti-pattern. In Review is type
custom, notclosed, so we keep counting it open. If the team’s intent is “review by self-checkout”, the right move is to map In Review →closedtype 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. - 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 Customerto typeclosedin Space Settings → Statuses (this is reversible). The connector will automatically drop these from the abandoned count on the next 5-minute poll. - 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
Reconciling against the vendor’s own dashboard
Where to look in ClickUp’s own UI:app.clickup.com then for eachClickUp 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:vortex_iq_outboundList, switch to List view, click Filter, and add three filters:Custom Field → vortexiq_finding_id → has any value,Status → is not Closed, andDate 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.
Cross-connector reconciliation. ClickUp abandoned vs incident-management peers:
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’sdate_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.