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 Basecamp to-dos in the Vortex IQ Findings list whose updated_at has not changed in 14+ days. On Basecamp this card carries more weight than on richer PM tools, because Basecamp does not give the team any other staleness signal (no priority field, no last-touched warning, no auto-reminders). If this number climbs it is the single most reliable signal that operational discipline is regressing on a Basecamp team.
| What it counts | Open to-dos in the mapped Vortex IQ Findings list with completed = false AND updated_at older than 14 days. The 14-day window is fixed by default; tunable per organization in connector settings. |
| API endpoint | GET /buckets/{project_id}/todolists/{list_id}/todos.json paged via Link header. Vortex IQ filters server-side by completed=false and applies the 14-day staleness check client-side because Basecamp’s REST surface does not expose updated_since for the to-do endpoint. |
| What counts as “movement” | Any of: assignee change, due-date change, comment posted, description edit, name edit, or completion. Basecamp updates updated_at on any of these. What does NOT count: a teammate opening the to-do to read it (Basecamp does not surface “viewed” events) and reordering the list (which Basecamp treats as a list-level operation, not a per-to-do edit). |
| Closed to-dos excluded | Yes. The moment a teammate ticks complete, the to-do drops out of this count on the next 5-minute polling cycle. |
| Archived projects | Excluded. Archived buckets return no to-dos via the API regardless of staleness. |
| Project / list scope | One Basecamp project (bucket) per connected workspace, with one named to-do list (default Vortex IQ Findings) inside it. Multi-project merchants connect each project as its own connection; this card aggregates across all connected projects unless filtered. |
| Time window | RT. The 14-day staleness clock is rolling, evaluated on every 5-minute poll. |
| Alert trigger | > 5 (warn), > 15 (critical). The warn threshold catches early stagnation; the critical threshold reflects systemic execution failure. On Basecamp specifically, more than 15 stale to-dos in a flat to-do list is the point where the list itself becomes uncomfortable to scroll, which feeds the staleness compounding. |
| Sentiment | Threshold-based, {warn: 5, critical: 15}. |
| Time zone | updated_at is ISO-8601 UTC. The 14-day cutoff is applied in UTC. |
| Multi-account aggregation | Yes by default; per-account stack panel available. |
| Polling lag | Up to 5 minutes (Basecamp does not yet emit per-to-do webhooks). |
| Roles | owner, operations |
Calculation
Calculated automatically from your Basecamp 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 14-person UK ethical-cosmetics brand on Shopify, marketing-led with a single ops manager and a contract dev. They run two Basecamp projects: DTC Storefront (marketing + ops) and Wholesale Portal (a small B2B side). Snapshot taken on 18 Apr 26 at 10:00 BST.| Basecamp project | Open findings | Abandoned (>14d no movement) | Notes |
|---|---|---|---|
| DTC Storefront | 13 | 6 | Mostly meta and og-image findings from the late-March campaign push, untouched since the marketing lead caught flu in early April. |
| Wholesale Portal | 5 | 4 | The dev contract paused for two weeks while waiting on supplier API approval; nothing moved. |
| Total open | 18 | 10 | Critical threshold reached. |
- Status is in warn, trending toward critical. 10 stale to-dos on a 14-person team is a meaningful queue-health regression. On Basecamp specifically, this is the card you need to read because the tool itself does not flag staleness anywhere in its UI.
- Both root causes are people-availability events, not capacity events. Marketing lead off sick, dev contract paused. The right action is not to staff up; it is to reassign the queue while the gap exists. Open Tickets by Assignee to see who else can carry the items.
- The Wholesale Portal cluster is the easier one to clear. Four findings on one project with a single root cause (dev paused) means either close them as Won’t Do if the supplier API decision changes the work, or reassign them as soon as the dev returns. Either way it is one decision, not four.
- The DTC Storefront cluster carries marketing-revenue risk. Six untouched meta/og-image findings since early April means roughly 4 weeks of organic-traffic regressions sitting in the queue. Pair this card with Google Search Console crawled-but-not-indexed counts to size the SEO impact.
- The right action is a 30-minute weekly triage. On a small team this is what stops staleness compounding. One ops lead walks the abandoned list, marks anything with no real merchant impact as completed (Basecamp does not have a Won’t Do state, so the team uses a comment + tick-complete pattern), and reassigns the rest. Most teams find 30-50% of stale findings should be closed-not-fixed.
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% means a third of the queue has gone dormant. On Basecamp this is the most common indicator of a broken triage rhythm. |
| 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 on a small Basecamp team. |
| 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 Assignee | Tells you whether abandonment concentrates on one person. | If most abandoned to-dos sit on one assignee (a common Basecamp pattern when one person owns a list), the fix is reassignment, not hiring. |
| Throughput Weekly | All-to-do completion rate, not just findings. | Strong overall throughput plus rising abandoned-findings means audit work is being deprioritised against client work or campaigns. |
| Throughput Trend | The slope. | A throughput dip preceding the abandoned spike is the canonical “team capacity dropped, queue piled up” sequence. |
| Sprint Progress | Basecamp does not have native sprints, but Vortex IQ derives a weekly batch from to-do creation cadence. | Low weekly progress + high abandoned = findings being created but never picked up. |
Reconciling against the vendor’s own dashboard
Where to look in Basecamp’s own UI:Basecamp does not natively expose an “abandoned” filter or any per-to-do staleness indicator. The closest manual equivalent is to open the project’s Activity feed (project home → Activity), scroll back two weeks, and look for to-dos that do not appear in the recent feed. This is genuinely awkward to do, which is why this card exists. A second-best option is to click into each open to-do in the Vortex IQ Findings list and read the Updates footer at the bottom of the to-do page; Basecamp shows the last edit time. Doing this 50 times by hand is the manual equivalent of the card.The honest read is: Basecamp does not surface this metric, on purpose, because the 37signals product philosophy holds that staleness should be addressed in human conversation rather than in tooling. We respect the philosophy by not writing a “stale” badge into Basecamp itself; we surface the count here, and the team is expected to act on it through their normal triage rhythm. Why our number may legitimately differ from a manual Basecamp staleness scan:
| Reason | Direction | Why |
|---|---|---|
| What counts as “movement” | Either | Vortex IQ reads updated_at directly. A teammate who only opens the to-do to read it does not move updated_at, so we still count it abandoned. A teammate who edits then reverts a description on the same day does move updated_at, so the timer resets even though no real progress was made. |
| Polling lag | Ours up to 5 min stale | A movement in the last 5 minutes is not yet reflected. |
| Time zone | Boundary day off | The 14-day cutoff is in UTC; a Basecamp UI viewed in your account-profile timezone may show a different “last edited” date for boundary-day to-dos. |
| Archived projects | Ours lower | Archived buckets return no items via the API; the team can still scroll into archived projects in Adminland. |
| List scoping | Ours scoped | Only the mapped Vortex IQ Findings list is read; if a teammate moved an abandoned finding into a different list, it drops out of our count. |
| Sub-tasks (Basecamp doesn’t have them) | n/a | Basecamp does not support sub-tasks; the card has no sub-task ambiguity to reconcile. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
datadog.dd_incidents_active | Independent. A live Datadog incident is a paging-grade engineering signal; an abandoned Basecamp finding is an organisational-discipline signal. | A growing Datadog incident count alongside a growing Basecamp abandoned count is the compound signal that engineering is firefighting and ops is falling behind simultaneously. |
newrelic.nr_open_incidents | Same shape. | Same reasoning. |
Known limitations / merchant FAQs
Basecamp shows my to-do was edited yesterday but you say it’s abandoned. What’s wrong? Almost always one of two things. (1) The “edit” was a Basecamp-internal re-index after an account-admin change, which we do not treat as movement; we readupdated_at directly and a re-index does bump it temporarily but the connector cross-checks against the Updates footer on a 5-minute cadence and self-corrects. Open the to-do and check the Updates footer at the bottom; if there is no human action in the last 14 days, our count is correct. (2) Polling lag: an edit made in the last 5 minutes may not have reached us yet; refresh in 5 minutes.
What counts as movement?
Any of: assignee change, due-date change, comment posted, description edit, name edit, or completion. What does NOT count: someone opening the to-do to read it (Basecamp does not surface “viewed” events) and reordering the list (Basecamp treats reorder as a list-level operation that does not bump per-to-do updated_at).
The 14-day window feels arbitrary. Can we tune it?
Yes, in Settings → Connectors → Basecamp → Abandonment threshold (days). We default to 14 days because it sits one full sprint plus a buffer. Basecamp teams are typically smaller than ClickUp or Monday teams, and small teams sometimes prefer a tighter 7-day window because their personal involvement with each to-do is higher; agency teams running multi-week client projects sometimes prefer 21 days. The right setting is the shortest one your team can act on without false alarms.
We have multiple Basecamp accounts (one per agency client). The count looks alarming.
Open the per-account stack panel from the connector drawer to see which account is driving the abandoned count. Agencies typically find the count clusters on one or two accounts that have been drifting between active phases (e.g. a client between campaign cycles). The actionable view is which client to put on the next triage call.
Resolution rate dropped, abandoned rising. What changed?
Standard playbook: (1) Open Tickets by Assignee and look for sudden concentration changes, a key person leaving, going on leave, or pulled onto another project is the single most common cause. (2) Open Throughput Trend; a throughput dip preceding the abandoned spike means capacity dropped first. (3) Cross-check against Datadog incidents; a sustained incident burst pulls the team off audit work for days at a time. The combination usually identifies the cause within minutes.
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 five to-dos were last touched on the same day exactly 14 days ago, all five 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 to-dos or fix them?
Both, depending on triage. Run a weekly 30-minute “abandoned review” with one ops lead. Basecamp does not have a Won’t Do state, so the convention is: post a comment on the to-do explaining the close decision, then tick complete. Most Basecamp teams find 30-50% of abandoned items should be closed-not-fixed; doing this triage once a week stops the queue compounding.
Is this the right card for my context, or should I focus on Findings Open?
On Basecamp specifically, this is the more important card. Findings Open tells you queue size; this card tells you queue health. Because Basecamp gives the team no other staleness signal natively, this card is doing work the tool itself does not. If you only watch one Basecamp findings card, watch this one. The open count can climb for healthy reasons (audit programme is finding more this week); a rising abandoned count almost never has a benign cause on a Basecamp team.
Why doesn’t Basecamp have a built-in “abandoned” view?
Because 37signals deliberately does not build it. The product philosophy holds that staleness signals encourage management busywork; teams should triage in human conversation instead. We respect this by routing Vortex IQ to one to-do list per project and surfacing the staleness rollup here in Vortex IQ Nerve Centre rather than asking Basecamp to produce one. The same applies to Trello (no abandoned filter), ClickUp (no abandoned filter), Monday (no abandoned filter), Linear (no abandoned filter); none of them ship an abandoned-task primitive, all of them have task-modification timestamps we can read.
Today’s count looks volatile. Why?
At low volumes (under 5 abandoned) a single “movement” event resets the timer on one to-do and drops the count by 20%. Over 7 days the trend smooths out; the headline number is the live count, the 30-day average shown beneath is the steadier read.