Skip to main content
Metrics type: Cross-Platform Metrics • Category: Project Management
How fast we get findings into Jira after detection. Slow dispatch = cold leads by the time the ops team sees them.

​
At a glance

p95 of time-from-finding-detection-to-Jira-ticket-existence over the trailing 30 days. Measures the responsiveness of the Vortex IQ → Jira dispatch pipeline. Healthy dispatch is sub-2-minute p95; anything north of 2 hours means findings are arriving cold to a team that has already moved on to something else.

​
Calculation

Calculated automatically from your Jira 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 UK retailer on Shopify, mid-sized team, audit cycle runs every 6 hours. Reading taken at 11:00 GMT on 04 Apr 26, 30-day window covers 05 Mar 26 to 04 Apr 26. The card reads 47 seconds at p95, alert at >2h p95 is comfortably clear (well under threshold). What this tells the merchant:
  1. Healthy dispatch. Sub-minute p95 is the gold standard. The audit team can trust that any finding the merchant looks at the next morning was filed within seconds of detection, the audit and the ticket reference the same world.
  2. The p99 of 38 minutes flags a bulk-create stampede. Once or twice in the 30-day window an audit cycle produced 80+ findings simultaneously (typically the post-deploy audit after a major release); Atlassian’s bulk-create endpoint rate-limited the burst, and the slowest 1 percent of dispatches sat in retry-with-backoff for up to 38 minutes. Pair with API Rate-Limit Headroom to see the corresponding headroom dip.
  3. The 4h 12m max is the token-rotation gap. On 23 Mar the merchant rotated their Atlassian token; for ~4 hours during business hours the dispatch pipeline retried-with-backoff until the new token was in place. The findings filed during that window dispatched as soon as the token was active. This is normal during planned rotations; the Atlassian Token Expiry Imminent card prompted the rotation.
Compare against the same merchant’s reading 8 weeks ago when they first connected: p95 was 12 minutes (slow). What changed: (1) audit-cycle frequency increased from daily to 6-hourly, smoothing the per-cycle batch size; (2) the merchant upgraded Atlassian to a paid tier with a higher API rate limit; (3) Vortex IQ pushed a release that added bulk-create batching. The result is a 15× improvement in p95 dispatch lag and a much-warmer hand-off into the engineering queue. The “lag suddenly spiked” debug case. If p95 jumps from 47s to 4h overnight, the cause is almost always one of: token expired (Atlassian Token Expiry Imminent), rate-limit exhausted (Rate-Limit Exhausted), or Jira project archived. Open those cards in that order; the root cause typically resolves in under 5 minutes.

​
Sibling cards merchants should reference together

​
Reconciling against the vendor’s own dashboard

Where to look in Jira: Jira does not publish per-ticket creation latency anywhere in the UI; it only records the created timestamp. To verify this card’s reading, you would compare the created timestamp on a Vortex-IQ-filed ticket against the corresponding Vortex IQ audit-finding detected_at timestamp:
  1. Open Vortex IQ → Audit → Findings → pick any recent finding → note detected_at.
  2. Click through to the linked Jira ticket → note Jira’s created timestamp.
  3. The difference is the per-finding dispatch lag.
The card’s p95 is the 95th percentile across all such pairs in the trailing 30 days. Why our number may legitimately differ from a manual spot-check: Cross-connector reconciliation:

​
Known limitations / merchant FAQs

Why does dispatch lag matter to a non-engineering owner? Because the audit→fix loop only works when the team treats findings as fresh. A finding that arrives 4 hours late is a backlog item; a finding that arrives in 4 seconds is an incident. The same finding has materially different operational consequences depending on dispatch lag, slow lag turns proactive monitoring into passive ticketing, which the team will deprioritise. My p95 jumped from 30 seconds to 4 hours overnight. What’s the playbook? Three-step diagnosis. (1) Open Atlassian Token Expiry Imminent first, expired tokens cause infinite-retry-with-backoff which shows up as multi-hour p95. (2) If token is fine, open Rate-Limit Exhausted, Atlassian throttling adds backoff seconds that compound under load. (3) If both clear, check Vortex IQ’s status page for connector-side issues. The fourth less-common cause is a Jira project-level workflow change that broke ticket creation, see whether Critical Findings Without a Jira Ticket is also firing. Why is the alert at 2 hours and not 30 minutes? Calibrated against Atlassian’s published rate-limits and typical merchant dispatch volumes. Sub-2-minute p95 is healthy; 2 to 30 minutes is degraded but tolerable; 30 minutes to 2 hours is “rate-limit pressure during heavy audit cycles” which is recoverable; >2 hours statistically correlates with a sustained dispatch failure that needs human intervention. Tune the threshold in Settings → Alerts → Jira Dispatch Lag. Does this card include findings that the dispatch retried multiple times? Yes. The card measures time to first successful Jira ticket creation, regardless of how many retries happened. If a finding’s first dispatch attempt got a 429 and the second attempt at +60s succeeded, the lag is 60 seconds. Retry-count itself is on a separate operational dashboard not shown here. My team uses Jira Server (self-hosted), not Cloud. Does this work? Yes, with one caveat. Self-hosted Jira’s API can have different latency characteristics (especially on under-provisioned servers); typical p95 for a healthy self-hosted instance is 10 to 30 seconds rather than the sub-2-second Cloud baseline. The 2-hour alert threshold is the same; the green-state baseline is just slower. Monitor your self-hosted instance’s API latency separately. What’s a “normal” p95 for a healthy merchant? Sub-10 seconds is typical. The breakdown: <5 seconds is excellent (dispatch is essentially synchronous with detection); 5-30 seconds is healthy (occasional bulk-create backoff); 30 seconds to 2 minutes is “heavy audit cycle days”; 2-30 minutes suggests rate-limit pressure to investigate; >30 minutes is degraded; >2 hours is failing. Track the trend, not the absolute, a slowly creeping p95 is the early-warning shape. My audit cycle just produced 200 findings. Will this card spike? Briefly, yes. Bulk-create batches of 200 hit Atlassian’s rate-limit ceiling and the slowest 5 percent will sit in retry-with-backoff for 30 to 90 seconds. The 30-day rolling p95 absorbs this with minimal movement. If your audit cycles routinely produce 200+ findings, consider tuning the audit cadence in Settings → Audit → Schedule to spread the dispatch load. Why don’t you measure mean / average lag instead of p95? Average is dominated by the fast median and hides the slow tail. The merchant doesn’t care about the typical experience; they care about the worst-case experience, “what’s the longest a critical finding might wait before it lands in the queue”. p95 is the cleanest single number for that. p99 is on the dashboard for completeness but adds little signal beyond p95 except for flagging extreme tails. Does dispatch lag affect Vortex IQ’s audit accuracy? No. The audit detects findings independently of dispatch; lag only delays visibility to the engineering team, not detection itself. The audit-finding record is durable from the moment of detection, the Jira ticket is the merchant-facing surfacing of that record. If dispatch is broken for a day, every finding is still in the Vortex IQ audit-finding registry; the team just doesn’t see them in Jira until the pipeline recovers.

​
Tracked live in Vortex IQ Nerve Centre

Finding-to-Ticket Dispatch Lag is one of hundreds of KPI pulses Vortex IQ tracks across Jira and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.