At a glance
Of the findings Vortex IQ created in your Notion workspace in the last 90 days, the percentage that you’ve moved into a Done-group status. The single number that says “is the team keeping up with what we surface?”
| The formula | resolved_in_window ÷ created_in_window × 100, where the window is the last 90 days based on Notion’s Created time system property. A finding created on day -91 is not in the denominator even if it was closed yesterday. |
| What “resolved” means | The row’s Status is in the merchant-mapped Done group at the moment of the read. The row may have moved through To-do → In progress → Done, or jumped directly To-do → Done (e.g. “Won’t fix”). Both count as resolved for this card. |
| Why “Won’t fix” counts as resolved | Because the team made a decision. The opposite (a row sitting open forever) is the failure mode. We measure decision-throughput, not just shipped-fixes. If you want to separate the two, see FAQs. |
| Why 90 days | Long enough to smooth out fortnightly noise, short enough to react to recent changes. The 90D window is fixed at the manifest level. |
| Database property scheme | Reads Status (status type) and Created time (system property). Both are required, the connector verifies them at setup time and refuses to enable until the database has both. |
| Resolved vs closed | Notion has no “closed” concept distinct from status. We treat any value in the Done group as resolved. There is no separate “Resolution” property to read (unlike Jira). |
| Time window | 90D (rolling). |
| Alert trigger | <50%, the team is closing fewer than half of new findings within the window. |
| Sentiment key | {'type': 'gauge', 'thresholds': {'good': 75, 'warn': 50}}. Above 75% reads green, 50, 75% reads amber, below 50% reads red. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Notion data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
Same UK fashion brand. The Notion Site Improvements database, looking at the 90-day window ending 12 Mar 26.| How they were resolved | Count | Counts toward this card? |
|---|---|---|
| Status changed to Done after dev work | 31 | yes |
| Status changed to Won’t fix (decision) | 9 | yes |
| Status changed to Done (deduplicated against another finding) | 4 | yes |
Sibling cards merchants should reference together
Resolution Rate is the throughput indicator. Always read with:| Card | Why it matters next to Resolution Rate | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | The current queue depth. | High Open + low Resolution = team is genuinely behind. Low Open + low Resolution = inflow is low; the rate is calculated on a small sample, ignore it for a sprint. |
| Abandoned Findings (>14d no movement) | Tells you whether resolution is happening evenly or only on the easy ones. | Resolution 70% + Abandoned high = team picks the quick wins, leaves the hard ones to rot. The composition matters. |
| Avg Time-to-Fix | Speed per finding. Rate is volume; Time-to-Fix is per-unit speed. | High rate + low Time-to-Fix = excellent. High rate + high Time-to-Fix = “we close them but only after 30 days each” (suggests batching). |
| Sprint Velocity (avg) | Team’s overall throughput across all work, not just findings. | If Sprint Velocity is healthy but Resolution Rate is low, findings are deprioritised. Conversation: are they being deprioritised correctly? |
| Tickets by Assignee | Which person owns most resolved/unresolved. | If 80% of resolved are from one person, you have a key-person dependency. Spread the work. |
Reconciling against the vendor’s own dashboard
Where to reproduce this in Notion itself: Notion has no native rate calculation, but you can produce both numerator and denominator with two filtered views:
Denominator (created in window):
Findings database → New view → Table.
Filter: Created time is on or after today − 90 days.
Row count = denominator.
Numerator (resolved within window): Same database → New view → Table. Filter:Divide. The percentage should match this card to the nearest 1% (small drift from sync timing, see below). Why our number may legitimately differ from your hand calculation:Created timeis on or after today − 90 days ANDStatusis in Done. Row count = numerator.
| Reason | Direction | Why |
|---|---|---|
| Sync lag | Either | The 60-second sync window means status changes in the last minute may not be reflected. Doesn’t typically move the percentage by more than 1, 2 points. |
| Rounding | Either | The card rounds to the nearest whole percent; your hand-calc might keep two decimals. 70.97% becomes 71%. |
| Time-zone boundary | Edge cases | We compute “90 days ago” in UTC. A finding created at 02:00 GMT on day -90 is in our window if you’re in the UK; a merchant in California (UTC-8) might compute the boundary differently and exclude it. |
| Permission scope | Yours possibly lower | If your Notion view is filtered by “shared with me”, you’ll see fewer rows than the connector token. Always filter by the database itself, not by share status. |
resolved_in_window ÷ created_in_window × 100, rolling 90D). Comparing percentages across connectors is meaningful: a 70% rate in Notion and 70% in Jira mean the same thing. However, switching destinations resets the population, if you previously wrote findings to Linear and switched to Notion last month, the Notion 90D denominator has 30 days of inflow, not 90. Wait for the full 90 days before reading the percentage as stable.
Known limitations / merchant FAQs
What’s a “good” Resolution Rate? Above 75% (green) is healthy. 50, 75% (amber) means the team is keeping up but slipping. Below 50% (red) means findings are accumulating faster than they’re being closed and the queue will keep growing. Note: 100% is not the goal, that usually means the team is closing things they shouldn’t (e.g. real bugs marked Won’t fix to make the number look good). Why does the number drop after a quiet week? Because the denominator is a rolling 90-day window. If your team takes a week off and stops moving rows to Done, the resolved count falls but the created count (a window-anchored figure) keeps the same shape. The rate drops mechanically. It will recover when the team comes back. This is a strength, not a bug, the number is honest about pauses. Should I count “Won’t fix” as a resolution? Yes. The decision to not fix something is a valid resolution. The thing we want to penalise is rows sitting open with no decision at all (see Abandoned Findings). That said, if your “Won’t fix” rate is high (>30% of resolutions), that’s worth a conversation: are the findings poorly targeted? Tune Vortex IQ’s finding rules in Settings → Audits. My team uses a custom status called “Validated, awaiting deploy”. Should it be Done or Open? Depends. If “Validated” is the team’s signal that the work is finished from a planning perspective and the deploy is just operational, map it to Done. If validation is genuinely a check-step that could still bounce back, leave it in In progress. Map intent, not workflow stage. Is the rate a trend or a snapshot? Snapshot, calculated on every read. The card shows today’s percentage; for the trend, look at Throughput Trend (which uses the same data shaped as a sparkline). Vortex IQ stores the daily snapshot history and Ask Viq can answer “how did Resolution Rate move over the last quarter?” in plain English. What’s the right action when the gauge goes red? Three honest moves, in priority order:- Triage, run the same fortnightly triage we recommend for Abandoned. Bulk-close the findings that aren’t relevant to your business (with a “Won’t fix” reason). Mechanically lifts the rate and forces useful conversations.
- Cap inflow, in Settings → Audits, disable the lowest-priority audit modules. Stops the queue growing while you work down what’s there.
- Add capacity, only if (1) and (2) don’t fix it. Throwing people at a queue that’s growing because nobody is making decisions is a waste.