At a glance
Of every audit finding that landed in the Height workspace in the last 90 days, the percentage that has been moved to a Completed status. The headline number for “is Height actually serving as a delivery surface for our audit work, or just collecting tagged tasks the AI files but nobody finishes?” Pair it with the open count to grade the team’s flow. On Height specifically, this card matters more than on Jira because Height’s auto-categorisation can mask compounding backlogs, the rate is the cleanest signal that real throughput is keeping pace with intake.
Calculation
Calculated automatically from your Height 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 food and beverage DTC brand on Shopify, ~30 person team, runs delivery on Height with the audit-feed dispatcher live for 5 months. Snapshot taken on 02 May 26. Trailing 90 days: 03 Feb 26 → 02 May 26 (89 days).
The team is closing all the criticals (the on-call rotation surfaces them on Height’s “Today” view via auto-prioritisation), almost all the highs, and roughly 70% of the medium and low. The composite 84% is dragged slightly by the long tail of low-severity items.
Compare to 60 days ago. Same brand, snapshot on 02 Mar 26: rate was 78%. The 6-point lift traces to a March process change, the team adopted Height’s new “Sweep” feature (a weekly auto-suggestion of stale tasks to triage), which materially helped clear the medium / low tail.
Compare to a peer brand on Jira. A similar-size US food brand on Jira runs the same audit-feed and sits at 71% in the same window. Same intake volume, same team size, but Height’s auto-prioritisation pulls the rate up by 10-13 points by surfacing the right work at the right moment. This is the measurable case for Height as a delivery surface, not just an onboarding-velocity surface.
The dangerous reading: rate at 41% on a workspace with 28 open findings. That is the “auto-categorisation hides a capacity problem” pattern, the AI keeps neatly filing findings into product-area lists, but nobody is closing them. The alert fires at 50% and pages owner + operations. By the time the rate is below 50%, the open count is usually compounding too; the team needs either a process intervention (capacity, scope, or pause auto-dispatch) or the audit cadence needs to slow.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Height’s own dashboard: Height does not provide a native “resolution rate” dashboard out of the box, the closest reconciliation uses a saved Smart List filter plus the workspace activity log.Height workspace → Filter bar → setFor Pro+ workspaces, Height’s Insights tab provides task-completion-rate analytics by tag, the chart matching this card is Insights → Completion rate → group by tag → tag = vortexiq:finding. Numbers should match within polling lag. Why our number may legitimately differ from a manual count in Height:Tag is vortexiq:findingANDCreated date is in the last 90 days→ save as Smart List VortexIQ 90d intake. Note the count. Then duplicate and addStatus is Completedto get the closed subset. Divide closed by intake to get the rate.
Cross-connector reconciliation:
Known limitations / merchant FAQs
Why is my Height rate higher than my Jira rate when both run on the same audit feed? Height’s auto-prioritisation surfaces the right work at the right moment, which materially lifts the visibility of audit findings inside the team’s daily workflow. On Jira, the same findings tend to sit in a “Bugs / Audits” backlog that nobody opens until sprint planning; on Height the AI puts them on the “Today” view of the right owner the moment they land. Same work, different surfacing, faster closure. Expect a 5-15 point Height advantage on Height-active teams. Why is my rate stuck at exactly 100%? Three possibilities: (1) very few findings in the window (e.g. 4 created, 4 completed); the rate looks great but the absolute volume is too thin to be meaningful, look at intake separately. (2) Auto-dispatch is misconfigured and findings are not reaching Height; the denominator is artificially small. (3) The team is closing tasks on creation as a workflow shortcut, which defeats the audit-tracking purpose, check the average time-to-fix sibling, if it is below 1 day on every finding, the closures are not real fixes. Why is my rate exactly 0%? Either no closures in 90 days (the team has not engaged with Height for VortexIQ work), or the team uses a custom non-terminal status they think is “Done” but Height treats as open. Check the workspace’s status enum, onlyCompleted counts as a resolution; a custom Shipped or Resolved status that is not mapped to the completed enum would not count.
Does cancelling a task hurt my rate?
No, neither helps nor hurts. Cancelled tasks are excluded from both terms, so the rate stays unaffected. This is intentional, a team that bulk-cancels false positives should not see the rate move just because they tidied up. The trade-off is that excessive cancellation can make a small denominator look smaller; if you are cancelling more than 20% of created findings, the audit rules need tuning, not the workflow.
Does a re-opened task hurt my rate?
No. Re-opening (Completed → Started) does not subtract from the numerator; only forward closures count. Re-opening a task adds to the open count (which surfaces on the Findings Open card) but does not penalise this card. The reasoning, regressions are a separate phenomenon from closure discipline, and double-counting punishes the team unfairly when they correctly catch a regression.
The rate dropped from 84% to 67% but no individual finding changed status. What happened?
Window-edge effects. The 90-day window is rolling, so tasks aged into or out of the window. Specifically, if a closure happened on day 91 (just outside the window now) and a creation was on day 90 (just inside), the rate would drop without any active behaviour change. This is normal noise; look at week-over-week change rather than day-over-day.
Should I optimise this number directly?
No. Resolution rate is a downstream indicator, not a target. Optimising it directly leads to bad behaviour, closing tasks without fixing the underlying issue, or refusing intake to keep the ratio healthy. Optimise throughput (more closures) and abandonment (fewer ignored tasks) and the rate follows. Treating the rate as a target produces the dashboard equivalent of teaching to the test.
Why 90 days, not quarterly?
A rolling 90-day window updates daily; a quarterly window resets every 90 days and creates artificial cliffs. Rolling is fairer for spotting trends and avoids end-of-quarter scramble gaming. Practically, 90 days is roughly equivalent to a quarter for benchmarking purposes.
My team uses Height for both engineering and product work. Should I expect the rate to be different on each?
Yes, slightly. Engineering-tagged findings typically resolve faster (median 4-7 days on a healthy team) than product-experience findings (median 8-15 days, more discovery and design time per fix). The composite rate captures the blend; if you want per-area resolution, use Height’s Insights tab to filter by list or label.
The card says my rate is healthy but the team complains audit-fixes never ship. What is going on?
Three usual causes. (1) The rate is high because Height auto-cancels stale tasks after 60 days and Vortex IQ excludes those from the denominator, the team is correctly perceiving that real fixes are not landing. Check the Cancellation Rate sibling. (2) Most closures are concentrated on low-severity items (you saw the worked example, 100% on critical and 70% on low produces a healthy composite even if the team’s perception is “criticals always slip”). (3) Height’s auto-prioritisation is closing tasks the team did not realise were closed (the AI moved them out of view because it judged them stale). Open the Insights tab and review by-severity closure rates, that is the breakdown that matches team perception.