Tickets we created from audit findings that haven’t been resolved yet.
At a glance
The live count of Height tasks Vortex IQ created from audit findings that have not been moved to a closed status. Height is the AI-driven autonomous PM tool (newer entrant alongside Linear and Asana) where tasks are auto-categorised, auto-tagged, and auto-grouped into lists by Height’s own model. Because Height handles a lot of the bookkeeping itself, this card is calibrated against a cleaner-than-Jira baseline, expect Height teams to clear faster on average and the >20 alert ceiling to fire later than it would on Jira.
| What it counts | Tasks in the configured Height workspace tagged vortexiq:finding (or with a Source field set to vortexiq) whose status.state is not in the completed or cancelled enum. Each finding maps 1:1 to one Height task; de-duplication is on the vortexiqFindingId custom field. |
| Workspace / list scope | The single Height workspace configured on the connector. Lists within the workspace are NOT filtered, every list inside the workspace is scanned. If the team uses Height’s auto-categorisation feature to spread VortexIQ findings across multiple lists (e.g. one per product area), the card aggregates across them. |
| Status filter | ”Open” means status.state of backlog, started, or any custom non-terminal state the team has defined. Height’s default status set is Backlog → Started → Completed → Cancelled, but workspaces can add custom states (e.g. In review, Blocked); any non-terminal custom state counts as open. |
| Issue type filter | All Height task types (Height does not enforce a type taxonomy the way Jira does). Subtasks inside a parent VortexIQ-finding task are NOT counted separately, the parent is the unit. |
| Resolution counts | A finding leaves the count when the task moves to Completed or Cancelled. Height’s auto-categorisation can occasionally move tasks between lists without changing status; those moves do not affect this card. |
| Auto-categorisation drift | Height’s AI auto-tags and auto-groups tasks based on title and description. If the auto-tagger removes the vortexiq:finding tag (rare but possible after a heavy edit), the task disappears from this count. Set protect_vortexiq_tag: true on the connector config to lock the tag. |
| Time window | RT (Height REST API polled every 60 seconds; webhook-driven on the Pro plan and above). |
| Alert trigger | >20 open. Calibrated 20% looser than Jira’s effective threshold because Height workspaces clear faster on average (auto-grouping + AI prioritisation reduce manual triage overhead). |
| 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. The auto-dispatcher routes audit findings into the Height workspace taggedvortexiq:finding. Snapshot taken on 02 May 26 at 11:00 EDT.
The team has Height’s AI auto-categorisation enabled, so VortexIQ findings spread across three auto-grouped lists:
| Auto-grouped list | Tasks tagged vortexiq:finding (open) | Tasks tagged vortexiq:finding (completed) |
|---|---|---|
| Storefront / Frontend | 7 | 22 |
| Checkout / Payments | 4 | 11 |
| Search / Catalogue | 3 | 8 |
- The 4 Checkout / Payments items are the most revenue-sensitive. All 4 are tagged
severity:critical(Stripe webhook retry loop spotted by the audit engine). - The 7 Storefront items are mostly
severity:medium(image-optimisation findings, alt-text gaps). - The 3 Search items are stale, none have moved status in the last 9 days (close to the 14-day abandonment threshold tracked by the sibling card).
severity:critical is in the description). Within 4 hours an engineer pairs on two of them and ships a fix. By end-of-day the open count drops to 12.
Why the threshold is 20 (looser than Jira’s effective 15): Height’s auto-grouping does the triage step the team would do by hand on Jira, an unsorted Inbox of 8 findings on Jira represents real cognitive load; the same 8 findings on Height arrive pre-grouped into the right product area with auto-suggested owners. The team’s effective triage cost is lower, so a higher standing count is acceptable.
The dangerous reading: open count above 30 with the Resolution Rate card below 50%. That is the pattern where Height’s auto-categorisation has masked a real capacity problem (the AI keeps neatly filing findings into lists, but nobody is closing them). When Vortex IQ sees both signals simultaneously it pages owner + operations and recommends pausing auto-dispatch for 7 days while the team catches up.
Compare to Jira on the same merchant. Pre-Height (12 months ago), this brand ran the same audit-feed into Jira and the open count routinely sat at 18-25. Same intake, same team, but Height’s auto-grouping reduced the perceived backlog by removing the “everything in one Inbox” friction. The absolute count of unfinished work is unchanged; the team’s tolerance for it is higher because the work is already organised.
Sibling cards merchants should reference together
| Card | Why pair it with VortexIQ Findings Open | What the combination tells you |
|---|---|---|
| Abandoned Findings (>14d no movement) | Subset of Open that has gone cold. The early-warning of a capacity gap. | Open rising and Abandoned rising together signals a real backlog problem, the AI auto-grouping cannot rescue it; Open rising while Abandoned is flat means the team is still actively triaging. |
| Finding Resolution Rate (90d) | The 90-day flow ratio. Counterweight to the live snapshot. | Open above 20 with rate below 50% means Height’s auto-categorisation is hiding a compounding backlog. Pause auto-dispatch until the rate recovers. |
| Throughput Trend (30d) | Weekly closure rhythm. Multiplied by 4 should approximate monthly intake at steady state. | Open count divided by weekly throughput equals weeks-of-work standing. 14 open at 5/week is roughly 3 weeks; manageable. 30 open at 4/week is 7+ weeks; intervene. |
| VortexIQ Findings Resolved (90d) | The completion peer. Same population, opposite end of the funnel. | Open + Resolved over 90 days equals total intake. Use the ratio to grade the audit programme’s actionability on Height specifically. |
| Datadog Operational Health Score | If Datadog health is dropping while Open is rising, the team is detecting more issues AND fixing fewer of them. | Worst-case combination, escalate on-call rotation. |
| Jira Findings Open | Cross-tracker peer. If your team uses Height for product work and Jira for engineering, both populated is normal. | Cross-tool concentration on the same finding indicates routing config drift, dedupe before triaging. |
| Critical Findings Without a Jira Ticket | Coverage-gap card. Routing-rules sanity check. | If criticals are landing on Height instead of Jira, the auto-router is wrong, criticals belong on the system that escalates and pages, not the one that auto-categorises. |
Reconciling against the vendor’s own dashboard
Where to look in Height’s own dashboard:Height workspace → open the workspace configured on the connector → use the global Filter bar at the top → setFor a deeper view, save the filter as a Smart List called Open VortexIQ Findings and pin it to the team sidebar. Height’s Smart List count refreshes every 30 seconds and matches this card within polling lag. Why our number may legitimately differ from Height:Tag is vortexiq:findingANDStatus is not Completed AND Status is not Cancelled→ the result count in the top-right of the filter pill matches this card.
| Reason | Direction | Why |
|---|---|---|
| Polling cadence | Ours stale up to 60s | REST API polled every 60 seconds on Free / Starter plans; webhook-driven on Pro+. A status change that just happened may take up to a minute to reflect. |
| Auto-categorisation tag drift | Ours lower | If Height’s AI auto-tagger removed the vortexiq:finding tag during a heavy edit (rare), the task disappears from the count. The Smart List in Height shows the same gap, so the manual count and this card stay in agreement, but both can drift from the intent of the dispatcher. Lock with protect_vortexiq_tag: true. |
| Custom non-terminal states | Possible mismatch | If the workspace adds a custom state called Done (lower-case), Height treats it as non-terminal unless the team explicitly maps it to the completed enum. Vortex IQ follows Height’s enum, so a Done-but-not-completed task counts as open. |
| Subtask boundary | Ours lower | A parent task with 5 unfinished subtasks counts as ONE open finding, not six. Height’s UI sometimes displays subtask counts in summary views which can confuse the manual reconciliation. |
| Archived workspaces | Ours skips | Archived workspaces are excluded from the count automatically. Height keeps archived workspace data accessible, but VortexIQ treats archive as “no longer in scope”. |
| Time zone | None | Real-time count, no period boundary. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
jira.jir_vortexiq_findings_open | Definitional twin if the team mixes Height (product) and Jira (engineering). The same audit finding can dispatch to both when both are configured as routing targets. | Jira count typically higher if engineering owns most findings; Height count higher when product / ops are the active triage layer. The gap tells you where the team’s real delivery surface lives. |
asana.asa_vortexiq_findings_open | Lightweight-PM peer. Asana and Height occupy similar territory but with different opinions (Asana is workflow-led, Height is AI-led). | Teams that switched from Asana to Height typically see a 20-30% lower standing open count once auto-grouping is calibrated, the work did not shrink, the perception of it did. |
linear.lin_vortexiq_findings_open | Closest peer for engineering-led teams that prefer keyboard-driven trackers. Linear and Height compete in the same modern-PM bucket. | Linear teams skew engineering-heavy; Height teams skew cross-functional. Open counts diverge based on who owns the audit feed. |
Known limitations / merchant FAQs
Why does Height feel “cleaner” than my Jira backlog with the same intake? Height’s AI auto-categorises and auto-groups tasks on creation, so 14 findings on Height look like three pre-sorted product-area stacks while 14 findings on Jira look like 14 unsorted tickets. The cognitive cost of a backlog is more about its layout than its size. Height’s pitch is real, but it does not actually shrink the work, only the perceived load. Use the Resolution Rate sibling to verify the actual throughput is keeping pace with intake. Height’s auto-prioritiser keeps re-ordering my list. Should I trust it? Height’s AI uses task description, age, status, and assignee load to suggest priority. For VortexIQ findings, it learns fromseverity:critical / high / medium / low tags in the description, so as long as the dispatcher sets severity correctly the auto-prioritiser will surface the right items. Do not turn auto-prioritisation off for this workspace unless you have a strong reason; turning it off removes Height’s main differentiator and you may as well run Jira.
Why is the alert threshold 20 when Jira’s effective threshold feels closer to 15?
Two reasons. (1) Height’s auto-grouping spreads findings across product-area lists, so 20 items distributed across 3 lists feel less heavy than 15 items in one Jira backlog. (2) Height teams empirically clear faster, the AI surface plus the keyboard-first navigation reduces the per-task triage cost. Calibrating to 20 keeps the alert paging-rate roughly equivalent across the two tools (Jira fires at 15 ≈ Height fires at 20 in measured merchant data).
My team uses Height’s “Today” view and ignores the global workspace. Will the count still be accurate?
Yes. The card counts open tasks regardless of which view a team-member is currently looking at. The “Today” view in Height is a personal filter; the underlying status of the tasks is what this card reads. If your team only ever uses “Today” they may not realise how many findings are sitting in the wider workspace, which is exactly why this card exists.
Why did the count drop sharply after a Height re-org last week?
Three usual causes after a Height re-org: (1) Tasks were moved to a workspace not connected to Vortex IQ, the connector lost sight of them; reconnect or move them back. (2) The auto-categoriser bulk-removed the vortexiq:finding tag during the migration, set protect_vortexiq_tag: true to prevent recurrence. (3) The team archived stale tasks instead of completing them, archived tasks do not count, so this is a real (if convenient) drop in scope.
Can I trust Height’s webhooks for real-time updates?
On the Pro plan and above, yes. Height’s webhook delivery is fast (median 200-400ms) and reliable. On the Free / Starter plans, polling is your only option and the count can lag up to 60 seconds. If the merchant is making decisions based on minute-by-minute readings, upgrade the Height workspace to Pro.
A teammate manually added the vortexiq:finding tag to a task they created. Will it count?
Yes. The tag is the filter. Manual additions count, which is by design (anyone on the team can promote a task into VortexIQ tracking). The downside is that manual additions do not get a vortexiqFindingId custom field, so they cannot be deduplicated against the audit feed; if the auto-dispatcher later creates a finding for the same issue, you may see two tasks for one underlying problem.
Why does this card matter to a non-engineering merchant?
Because Height is increasingly the system of record for product-led teams, and audit findings that land here are the ones the team actually intends to ship. If the open count is rising on Height, your team is committing to fixes faster than they are completing them, which compounds. The card is the early-warning version of the founder’s quarterly question “why are these audit issues taking forever?”, surfaced before that meeting happens.
Should this number ever be zero?
No, and zero usually means a problem. Audit detection runs continuously; a healthy team has 8-15 standing items at any moment because new findings arrive faster than they can be cleared individually. Zero either means auto-dispatch is broken (findings not reaching Height) or the team has bypassed Height entirely (fixing without tracking, which makes Resolution Rate unmeasurable).