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 Monday.com items in the Vortex IQ Findings board whose updated_at has not changed in 14+ days. Monday’s visual board layout makes accumulation feel less stressful than it is; an In Review or Stuck item can sit there for weeks while the team scrolls past it. This card cuts through that visual numbness by reading the modification timestamp directly.
| What it counts | Items in the connected Monday.com board with Status not in the closed set AND updated_at older than 14 days. The 14-day window is fixed by default; tunable per organization. |
| API endpoint | Monday.com GraphQL items_page(query_params: {rules: [{column_id: "status", operator: not_any_of, compare_value: ["Done","Cancelled","Won't Do"]}, {column_id: "__last_updated__", operator: less_than, compare_value: "14_days_ago"}]}). Monday’s rule-based GraphQL filter supports the staleness check natively. |
| What counts as “movement” | Any of: status change, person change, due-date change, comment posted, column-value edit, name edit, subitem added/removed. Monday updates updated_at on any of these. What does NOT count: viewing the item, board reorder operations (which Monday treats as board-level not item-level), and notification interactions. |
| Closed items excluded | Yes. The moment Status moves to a closed-set label, Monday’s webhook fires and the item drops from this count. |
| Archived boards | Excluded. Archived boards return no items via the API. |
| Workspace scope | All connected Monday.com workspaces, with the mapped Vortex IQ Findings board inside each. |
| Time window | RT. The 14-day staleness clock is rolling, evaluated on every webhook event with a 60-second poll safety net. |
| Alert trigger | > 5 (warn), > 15 (critical). Monday teams typically run between 3-8 abandoned because of the visual-numbness pattern; warn is the right early-warning threshold. |
| Sentiment | Threshold-based, {warn: 5, critical: 15}. |
| Time zone | updated_at arrives as ISO-8601 in your account-profile timezone via the GraphQL response; we normalise to UTC for the 14-day cutoff. |
| Multi-workspace aggregation | Yes; per-workspace stack panel available. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Monday.com 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 marketing-led DTC bedding brand on Shopify, 19-person team. They run two Monday.com boards: Vortex IQ Findings (audit work) and Campaign Calendar (marketing planning). Snapshot taken on 02 May 26 at 13:30 BST.| Monday.com Status (open labels) | Items | Abandoned (>14d) | Notes |
|---|---|---|---|
| Working on it | 9 | 1 | One image-CDN finding the developer started two months ago and never returned to. |
| Stuck | 3 | 3 | All three flagged Stuck over 14 days ago, “blocked on partner” was the comment but no follow-up. |
| In Review | 6 | 4 | Four items have been In Review since the marketing director’s last review meeting before Easter, classic visual-numbness pattern. |
| Total open | 18 | 8 | Warn threshold crossed. |
- Status is in warn, sharp delta vs 30D average. 8 stale items on a 19-person Monday team is the visual-numbness pattern at full strength. The board looks busy and active; the timestamps say otherwise.
- The In Review cluster is the most actionable. Four items have been In Review since the last director’s review meeting. The fix is not technical, it is to schedule the next review meeting and walk these four items through. In Review on Monday teams is the single most common parking-space label.
- The Stuck cluster needs explicit unblocking. Three items flagged Stuck over 14 days ago means “blocked” became “forgotten”. Each Stuck item needs a comment with a date and a person owning the unblock; if neither exists, the right move is to close the item with a Won’t Do and raise it again if it becomes blocking later.
- The single Working on it stale item is the developer-attention pattern. When one developer holds an item in Working on it for weeks, Monday’s visual board does not flag it; this card does. Reassign or break it down.
- The right action is a 20-minute weekly board review. On a Monday-led team, the discipline that closes this gap is a recurring “stale items walk” at the marketing operations meeting, with one rule: any item over 14 days old gets a decision now. Most teams find 30-50% of stale items should be closed-not-fixed via Won’t Do.
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 30% = a third of the queue gone dormant; on Monday this is the most common signature of visual-numbness. |
| Finding Resolution Rate (90d) | Resolution rate drops first, abandoned 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 = team is starting then stalling, not refusing the work. |
| Tickets by Assignee | Whether abandonment concentrates on one Person. | On Monday teams, stale items often cluster on the marketing-ops lead. |
| Backlog by Priority | What’s open by importance. | Abandoned items in High priority are the actionable-now set; abandoned in Low should mostly be closed. |
| Sprint Progress | Whether items are entering a planned weekly batch. | Items that never enter a weekly batch are the ones that abandon. |
| Scope Added Mid-Sprint | Mid-week scope creep crowds out audit findings. | High scope creep + rising abandoned = team is reactive, not proactive. |
Reconciling against the vendor’s own dashboard
Where to look in Monday.com’s own UI:monday.com then open the Vortex IQ Findings board. Click Filter, addFor multi-board rollups, Monday’s Dashboards module supports a Numbers widget with the same filter shape, useful when an agency runs Vortex IQ across multiple client boards. Why our number may legitimately differ from a saved Monday filter:Status → is not → Done, Cancelled, Won't Do, then addLast updated → before → <14 days ago>. Save the view as Stale Findings so the team has a one-click view. Monday’s filter for “Last updated” reads the system column we use, so the count should match this card closely (subject to timezone and webhook-delay caveats).
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary day off | Monday’s UI uses your account-profile timezone for the “before <14 days ago>” filter; we apply the cutoff in UTC. |
| Status label mapping | Either | We use the configured closed-label set; if your saved filter excludes additional labels (e.g. On Hold), the saved filter will be lower. |
| Subitem handling | Ours can be lower | We count parent items only by default; subitems with their own vortexiq_finding_id count separately. |
| Cross-workspace aggregation | Ours wider | Monday’s UI scopes to one workspace; we sum. |
| Webhook delay vs polling | Ours up to 60s stale | Webhook + 60-second poll. |
| Updated-at granularity | Either | Monday’s __last_updated__ updates on a wide range of events (described in At a glance); a hand-eye scan of the activity feed may not match because some events update the timestamp without an obvious visible change. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
datadog.dd_incidents_active | Independent; weakly correlated. Marketing-led Monday teams have less direct production incident exposure than Linear teams. | A Datadog incident burst still slows the team’s audit triage rhythm, the lag is typically 2-3 weeks. |
newrelic.nr_open_incidents | Same shape. | Same. |
Known limitations / merchant FAQs
Monday says my item was updated yesterday but you say it’s abandoned. What’s wrong? Almost always the timezone or the polling cycle. Monday’s UI shows “updated yesterday” in your account-profile timezone; our 14-day cutoff is UTC. For boundary days the calendar day may differ. Refresh in 60 seconds. What counts as movement? Any of: status change, person change, due-date change, comment posted, column-value edit, name edit, subitem added/removed. What does NOT count: viewing the item, board reorder operations, notification interactions. Monday’s__last_updated__ system column captures all the events that count.
The 14-day window feels right for Monday but I want to tune it. Can I?
Yes. Settings → Connectors → Monday → Abandonment threshold (days). Marketing teams running weekly campaign sprints often tune to 7 days; agency teams managing multi-week client deliverables sometimes tune up to 21 days.
Our team uses In Review for marketing-director sign-off and it always sits there until the next review meeting. Should that count as abandoned?
Yes, if the meeting is more than 14 days away. The card’s value is exactly to surface this: a two-week sign-off cycle plus a 14-day staleness window catches reviews that were missed. The fix is either to schedule reviews more frequently, or to change In Review to a closed-set label (which records the item as resolved on the marketing side and creates a separate engineering item to ship from the approved version).
We have multiple Monday workspaces. The count looks alarming.
Open the per-workspace stack panel; on Monday the staleness usually concentrates on one workspace tied to a specific marketing channel that has cooled down (e.g. a paused influencer programme).
Resolution rate dropped, abandoned rising. What changed?
Standard playbook: (1) Tickets by Assignee for sudden concentration. (2) Sprint Progress for whether items are entering weekly batches. (3) Scope Added Mid-Sprint for interruptions.
The abandoned count appears suddenly higher overnight. Why?
The 14-day clock keeps ticking even when no one is editing. If 5 items 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 items or fix them?
Both, depending on triage. Run a weekly 30-minute “abandoned review”. Most Monday teams find 30-50% of stale items should be moved to Won’t Do; the remainder being correctly prioritised is the actual win, not the count itself.
Is this the right card for my context, or should I focus on Findings Open?
On Monday specifically this card is the queue-health indicator and arguably more important than Findings Open, because Monday’s visual board makes accumulation feel benign. The open count can climb while the team feels productive; the abandoned count is the truth-teller.
Why doesn’t Monday ship a built-in “abandoned” view?
Monday’s product strength is configurable visual layouts; “abandoned” is the kind of operational discipline metric that does not naturally fit a colour-coded Status column. The native primitive is Stuck, which depends on a teammate explicitly setting it; this card uses the system last_updated column to catch items that nobody flagged. Same applies to Asana, ClickUp, Linear, Trello, Basecamp, none of them ship an abandoned-task primitive natively.