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.
| The formula | (findings completed in last 90D) / (findings created in last 90D) × 100. Closures use the timestamp the task entered the Completed status. Cancellations are NOT counted as resolutions, a cancelled task is excluded from BOTH numerator and denominator (so a team that bulk-cancels stale findings cannot game the rate upward). |
| Why a 90-day window | Smooths out sprint-cadence variance and audit-batch effects (a single audit run can drop 8-12 findings at once and take 2-4 weeks to clear). A 30-day window swings wildly week-to-week; 90 days captures both intake spikes and the corresponding closure tails fairly. |
| Numerator (completed) | Count of tasks tagged vortexiq:finding whose status moved into Completed in the trailing 90 days. Re-opened tasks (Completed → Started → Completed) count once for each forward closure, regression handling is captured separately on the abandonment card. |
| Denominator (created) | Count of tasks tagged vortexiq:finding created in the trailing 90 days. Tasks created before the 90-day window are excluded from BOTH terms (so the ratio stays clean and old long-tail items do not pollute the recent-flow read). |
| Cancelled task handling | Cancelled tasks are excluded entirely. Height’s cancelled status is treated as “not relevant any more” rather than “fixed”, which is the right call for audit findings (a cancelled finding usually means the underlying issue was a false positive or the team decided not to act). |
| Edge case, zero creations | If no findings were created in the 90-day window the card displays -- (not 100% or 0%, both of which would be misleading). This happens when the auto-dispatcher is misconfigured or the team is off auto-dispatch. |
| Threshold rationale | Good ≥75%, warn 50-75%, critical <50%. Empirically Height teams with auto-categorisation enabled close 75-85% of findings within 90 days, slightly higher than Jira because the AI surfacing reduces forgotten-in-the-backlog patterns. The 50% critical line means the team is creating findings faster than they can resolve them. |
| Time window | 90D (rolling) |
| Alert trigger | <50% |
| Sentiment key | vortexiq_finding_resolution_rate, gauge-typed (good ≥75, warn ≥50) |
| Roles | owner, operations |
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).| Severity | Created (excl. cancelled) | Completed | Rate |
|---|---|---|---|
| critical | 11 | 11 | 100% |
| high | 22 | 21 | 95% |
| medium | 24 | 17 | 71% |
| low | 10 | 7 | 70% |
Sibling cards merchants should reference together
| Card | Why pair it with Resolution Rate | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | The numerator’s complement. Open is the queue at this instant; resolution rate is the long-window flow. | Open rising and rate falling equals a compounding backlog Height’s auto-categorisation has been hiding. Open falling and rate rising equals the team has caught up. |
| Abandoned Findings (>14d no movement) | Abandoned is the leading indicator of a falling rate. | Abandoned rising for 2-3 weeks reliably foreshadows a rate drop in the next 30-60 days, the signal arrives 4-8 weeks before this card moves. |
| Avg Time-to-Fix (days) | Cycle time on the resolved subset. The “how fast” peer to “how many”. | Rate at 80% with avg time-to-fix at 18 days = team gets there but slowly. Rate at 80% with time-to-fix at 4 days = fast and clean (Height’s typical signature when working well). |
| Throughput Trend (30d) | Weekly closure rhythm; multiplied by 12-13 weeks should approximate this card’s numerator. | Numerator divided by weekly throughput equals weeks tracked, sanity-check the arithmetic. |
| Datadog Operational Health Score | If Datadog health is dropping while Resolution Rate is dropping, the team is detecting more issues AND fixing fewer of them. | Worst-case combination, escalate. |
| Jira Finding Resolution Rate | Cross-tracker peer. Often the canonical engineering-led number for teams that mix Height (product) and Jira (engineering). | Jira rate higher than Height rate is unusual on Height-heavy teams (Height typically leads by 5-15 points due to AI surfacing); the gap reveals where the team’s real delivery rhythm is. |
| Linear Resolution Rate | Closest peer for engineering-led modern PM. | Linear and Height teams typically run within 5 points of each other; bigger gaps indicate one tool is the actual delivery surface and the other is window-dressing. |
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.
| Reason | Direction | Why |
|---|---|---|
| Cancelled task handling | Ours higher (cleaner) | Height’s UI counts cancelled tasks as part of the denominator in some report views. Vortex IQ excludes them from both terms. The result, this card reads 5-15% higher than the raw Height Insights view on workspaces that bulk-cancel false positives. |
| Re-opened tasks | Ours higher | If a task was Completed, then re-opened to Started, then Completed again, both forward closures count. A merchant counting “tasks currently in Completed” by hand only counts the latest state. |
| 90-day window edge | Boundary drift | Tasks created on day 91 of the trailing window are excluded; tasks on day 89 are included. The window slides daily. |
| Polling cadence | Ours stale up to 60s | Sub-minute closures lag in the rate on Free / Starter plans; Pro+ webhook delivery is near-real-time. |
| Time zone | Boundary days off | The 90-day window is computed in UTC; merchants in PST may see day-1 / day-91 boundaries shift relative to their working calendar. |
| Auto-categorisation tag drift | Ours lower | If Height’s AI auto-tagger removed the vortexiq:finding tag during a bulk edit, the task disappears from BOTH numerator and denominator. The rate stays roughly correct, but absolute counts shift. Lock with protect_vortexiq_tag: true. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
jira.jir_vortexiq_finding_resolution_rate | Definitional twin on Jira. Same window, same formula. Where both are connected and dispatch to both, the two rates measure overlapping but not identical populations. | Jira rate often lower for Height-led teams because Jira tickets sit in low-priority queues while the team’s real attention is on Height; the gap quantifies how much “real” work happens off the formal engineering tracker. |
asana.asa_vortexiq_finding_resolution_rate | Same metric on Asana, the lightweight-PM peer. | Asana rates tend to run 3-7 points behind Height because Asana lacks the auto-prioritisation step; same intake, slightly slower flow. |
linear.lin_vortexiq_finding_resolution_rate | Closest peer for engineering-led modern PM. | Linear teams typically run within 5 points of Height; bigger gaps indicate one tool is the active delivery surface and the other is shadow-tracking. |
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.