At a glance
The percentage of Vortex IQ findings created in ClickUp in the last 90 days that have reached aclosed-type status. ClickUp’s headline strength is its all-in-one configurability; the cost of that configurability is that “resolved” can be hard to define. This card cuts through by readingstatus.typedirectly: onlyclosedis resolved. Below 50% the team is falling behind; above 75% it’s keeping up.
| The formula | resolved_in_window ÷ created_in_window, where resolved_in_window counts ClickUp tasks with vortexiq_finding_id, status.type = 'closed', and date_closed (or date_done for legacy task variants) within the 90-day window; created_in_window counts tasks with the same custom-field set and date_created within the same window. |
| API endpoints | GET /api/v2/list/{list_id}/task paged with archived=false&include_closed=true&order_by=created and subtasks=true for nested findings. We bucket by vortexiq_finding_id to avoid double-counting if a finding was re-created. |
| Window | Rolling 90 days, refreshed hourly. Real-time refreshes happen on every ClickUp webhook event for the live count, but the rate calculation is hourly to smooth single-task volatility. |
| What “resolved” means | status.type = 'closed' only. Statuses with type open, custom, or done are NOT counted as resolved. ClickUp’s done type is treated as not-yet-resolved because some teams use Done as a review-pending state before Closed. |
| Won’t Do treatment | A task moved to a custom closed-type status named Won’t Do counts as resolved. We treat both decisions (fix it, decide not to fix it) as resolutions because closing the loop is what the rate measures. |
| Project / List scope | All vortex_iq_outbound Lists across all Spaces in all connected Workspaces. |
| Archived containers | Excluded from both numerator and denominator. |
| Time zone | date_closed and date_created are Unix epoch ms (UTC). The 90-day window aligns to UTC. |
| Alert trigger | < 50% raises a critical alert. |
| Sentiment thresholds | Gauge: green ≥ 75%, amber 50-74%, red < 50%. |
| Multi-workspace aggregation | Yes, computed on summed numerator and denominator. Per-workspace stack panel available. |
| Roles | owner, 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; the brand has four Spaces (Marketing, Catalogue, Engineering, CX) with bespoke status spectrums per Space. Snapshot taken on 02 May 26 at 09:45 EDT.| Last 90 days (02 Feb 26 - 02 May 26) | Count |
|---|---|
Findings created (ClickUp tasks with vortexiq_finding_id, date_created in window) | 112 |
Findings resolved (above set, AND status.type = 'closed', date_closed in window) | 76 |
| Findings still open from window | 30 |
| Findings re-created within window (counted once on first close in numerator) | 6 |
- 68% sits in the amber band (50-74%). Above the alarm threshold but below the green target. The team is closing more than it is opening, but the open queue shrinks slowly. Acceptable, not great.
- The open queue will not collapse to zero. At 68% resolution rate, expect roughly 25-35 open findings as a steady-state on a 32-person ClickUp team. Anything beyond that is the team falling behind; anything below it is the audit programme finding less than usual.
- Pair this card with Avg Time-to-Fix. A 68% rate with a 7-day mean time-to-fix is healthy. A 68% rate with a 25-day mean time-to-fix means the team is closing the easy items and stalling on the harder ones, the classic ClickUp pattern when custom statuses become parking spaces.
- The Engineering Space probably runs higher than 68%; the Marketing Space probably runs lower. Open the per-Space stack panel to see this breakdown. ClickUp Spaces with strict
closed-type rules (typical of Engineering with Sprint commitments) usually run 80-90%; Spaces with permissive custom statuses (typical of Marketing with In Review and Awaiting Customer) usually run 50-65%. The blended rate is an organisation-level number; the per-Space number is operational. - The team should aim for 75% sustained. Below 50% is alarm territory; above 75% means the team is keeping up with intake. The fastest way to lift a ClickUp rate is to audit the per-Space status taxonomy: any custom status that genuinely means “the team has done its part” should be
closedtype, notcustomtype.
Sibling cards merchants should reference together
| Card | Why pair it with Resolution Rate | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | Resolution rate’s denominator-half. | Falling rate plus climbing open count = capacity bottleneck; falling rate plus flat open count = audit programme finding less. |
| Abandoned Findings (>14d) | Tasks that count in the denominator but never become numerators. | High abandoned plus low rate equals execution discipline gap; low abandoned plus low rate equals the team is engaged but underwater. |
| Avg Time-to-Fix (days) | Time-to-fix is the cycle time inside this rate. | High rate plus low time-to-fix equals excellent. High rate plus high time-to-fix equals closing eventually but slowly. |
| Tickets Resolved (7d) | Short-window throughput of all tasks. | High overall throughput but low findings rate equals audit work being deprioritised. |
| Sprint Velocity (avg) | The team’s capacity ceiling. | A flat rate with rising velocity equals audit work not reaching sprints. |
| Throughput Trend | The slope. | A rate dipping while throughput climbs equals deliberate prioritisation away from audit work. |
| Sprint Progress | Whether findings are getting committed to the current sprint. | Low sprint progress + low rate = findings queued but never pulled in. |
Reconciling against the vendor’s own dashboard
Where to look in ClickUp’s own UI:
app.clickup.com then open the Dashboards module (Unlimited and above). Add a Tasks completed vs Tasks created chart, set the time range to Last 90 days, and add the filter Custom Field → vortexiq_finding_id → has any value. ClickUp’s Dashboards also support a Completion rate widget (a single percent number) that approximates this card directly; pin it to a workspace dashboard for a side-by-side glance. ClickUp’s Goals module surfaces a similar completion-rate gauge for goals tied to specific Lists.
ClickUp’s Dashboard widgets cannot be filtered by status.type directly; they filter by status name. This is the most common reason a Dashboard widget rate differs from this card.
Why our number may legitimately differ from a ClickUp Dashboard widget:
| Reason | Direction | Why |
|---|---|---|
| Status-type vs status-name | Either | We treat status.type = 'closed' as resolved. A Dashboard widget filtered “Status is Closed” matches us; a widget filtered “Status is Closed OR Done OR Resolved” will be higher because it counts done-type statuses we keep open. |
| Window definition | Either | ClickUp’s Dashboard “Last 90 days” rolls daily at midnight in your account-profile timezone; our window rolls hourly in UTC. |
| Re-created findings | Ours lower | If a finding was closed, re-opened, and closed again within 90 days, ClickUp’s Dashboard counts both completion events; we count once per vortexiq_finding_id. |
| Subtask handling | Either | Our count uses parent tasks (where the custom field lives). ClickUp’s chart can be configured to include or exclude subtasks. |
| Archived containers | Ours lower | Archived Lists/Spaces drop from both numerator and denominator; ClickUp’s chart can include archived if configured. |
| Cross-workspace aggregation | Ours wider | Dashboard widgets are per-Workspace by default; we sum across all connected Workspaces. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
datadog.dd_health_score | Independent. Datadog Health is server-side production health; ClickUp resolution rate is internal team operations. | A high Datadog Health Score with a low ClickUp resolution rate means production is fine but the team is falling behind on the work that prevents future regressions. The cause-and-effect lag is typically 2-6 weeks. |
newrelic.nr_apdex | Same shape. | Same lag. |
Known limitations / merchant FAQs
My ClickUp Dashboard widget shows 75% but you say 68%. What’s wrong? Seven points of gap is normal. The usual reasons in order: (1) Status-type vs status-name: we count onlyclosed type as resolved; your Dashboard widget filtered by status name may also include done-type statuses (which we keep open). (2) Re-opened tasks: ClickUp counts each completion event; we count once per finding-id. (3) Cross-workspace aggregation: we sum across connected Workspaces. (4) Subtask handling. Open the per-Workspace stack panel and the gap usually closes to within 2-3 points.
Does “Won’t Do” count as resolved?
Yes, if the Won’t Do status is type closed. From the audit programme’s perspective, both decisions are resolutions. Verify the type in Space Settings → Statuses, if your Won’t Do is custom rather than closed, change it; otherwise it stays counted as open.
ClickUp’s done and closed types are confusing. Which one matters?
Only closed. ClickUp’s data model has four status types: open, custom, done, closed. The done type was introduced as an intermediate “ready for review” stage; teams that use Done as the final state should change its type to closed (this is reversible). The connector reads status.type directly, not the status name, so renaming a status without changing its type does nothing.
Our rate sits at 45%. Should I be concerned?
Yes. Below 50% is the alarm threshold. The standard playbook is the four-card investigation: open this card, Findings Open, Abandoned Findings, and Tickets by Assignee side-by-side. Within 5 minutes you’ll know if it’s a single-assignee bottleneck (most common), a Sprint-planning bottleneck, or a status-taxonomy issue (a Space’s In Review or Awaiting Customer status should probably be type closed).
We use multiple ClickUp Workspaces. Which workspace’s rate matters most?
The one with the lowest rate is the leading indicator. Open the per-workspace stack panel from the connector drawer to see them broken out. Marketing-led Workspaces typically run lower (50-65%) than Engineering-led Workspaces (80-90%) because of status-taxonomy differences.
Throughput dropped this week, rate is still high. What’s happening?
“Team closed everything easy and left the hard stuff.” Open Avg Time-to-Fix, if mean cycle time climbed alongside the throughput drop, the team has finished quick-wins and is now starting on heavier findings. Healthy phase, lasts 1-3 weeks.
Today’s rate looks volatile. Why?
At low resolution volumes the rate is sensitive: 5 resolutions out of 8 is 62.5% and one extra close moves it to 75%. The 90-day window makes daily volatility small but visible. The 7-day moving rate (shown on the trend line) is less noisy.
Multi-team reporting: how do I see resolution rate by team within one Workspace?
ClickUp’s Spaces are the natural team boundary. The per-Space stack panel surfaces the per-team rate. If you need finer-grained “team within Space” reporting (e.g. two product squads sharing one Engineering Space), the workaround is to split into one Folder per squad and tag each Folder as a separate vortex_iq_outbound route in connector setup.
Is ClickUp the right tool for tracking this metric?
For mid-market ecommerce teams that want one tool to do everything, yes. ClickUp’s per-task time-tracking, goal-linking, and document attachments make it a natural fit when ops, marketing, and engineering all share one workspace. The cost is configuration overhead: the more custom statuses you create, the more decisions Vortex IQ needs about which count as resolved. Asana is closer for cross-functional ops/marketing teams that want portfolios; Linear is closer for engineering-only teams that want cycle-time metrics; Monday is closer for visual-planning teams; Smartsheet is closer for spreadsheet-style PMOs. ClickUp’s strength here is the breadth: this card sits comfortably alongside time-tracking and goal cards on a single ClickUp dashboard.
Resolution rate climbed but I don’t think the team did anything different. What changed?
Three usual causes. (1) Audit programme produced fewer findings (denominator shrank). Check Findings Open trend. (2) A bulk closure (the team did an “abandoned review”). Check ClickUp’s Audit Log under Workspace Settings. (3) A status type was changed from custom to closed for an existing custom status; tasks in that status now count as resolved overnight. Check Space Settings → Statuses edit history.