> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Finding-to-Ticket Dispatch Lag, Jira > How fast we get findings into Jira after detection. Slow dispatch = cold leads by the time the ops team sees them. How to read it, why it matters, and how ... **Metrics type:** [Cross-Platform Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Project Management](/nerve-centre/connectors#connectors-by-type) > 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. | | | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `p95(jira.tracker_item.created_at - audit_finding.created_at)` over the trailing 30 days, for findings that have a Jira ticket. Findings without a ticket are out of scope here, see [Critical Findings Without a Jira Ticket](/nerve-centre/kpi-cards/jira/critical-findings-without-a-jira-ticket) for that gap. | | **Why p95 not avg** | The merchant cares about the *worst-case* dispatch experience, not the typical one. Avg is misleading because batch-dispatch is fast for the median and slow for the tail. p95 cleanly captures the experience of the slowest 5 percent of findings, which is where the operational pain lives. | | **Why merchant-impact matters** | Slow dispatch erodes the audit→fix loop's value. A finding detected at 09:00 and ticketed at 09:01 lands while the audit context is fresh; the same finding ticketed at 16:00 lands six hours after detection, by which time the audit run, the page deploy that caused it, and the customer-impact wave have all moved on. The team treats it as a backlog item, not an incident. | | **Typical lag sources** | (1) Atlassian API rate-limit backpressure (most common). (2) Bulk-create stampede after an audit cycle that produces 50+ findings simultaneously. (3) Token rotation gap (lag temporarily infinite during the rotation window). (4) Custom-field validation failure causing the API call to retry. (5) Jira project being archived mid-dispatch. | | **Bulk vs individual dispatch** | Vortex IQ uses Atlassian's bulk-create endpoint (`POST /rest/api/3/issue/bulk`) when 5+ findings dispatch in a 60-second window, individual `POST /rest/api/3/issue` otherwise. Bulk-create's p95 is typically 3 to 10 seconds; individual is sub-2 seconds. Lag rising past 60 seconds means either rate-limit backpressure or a pipeline-side bug. | | **Severity weighting** | All severities count equally toward p95. Critical findings dispatched 2h late are no less of an alert than Medium findings dispatched 2h late, but the *consequence* of late Critical dispatch is materially worse; pair with [Critical Findings Without a Jira Ticket](/nerve-centre/kpi-cards/jira/critical-findings-without-a-jira-ticket) to see severity context. | | **Refresh cadence** | Recomputed every 5 minutes. The 30-day rolling p95 is robust to short-window noise. | | **Time window** | `30D` (rolling 30 days). | | **Alert trigger** | `>2h p95`. Anything beyond 2 hours indicates pipeline degradation worth investigating; healthy is sub-2-minute. | | **Roles** | owner, operations | ## 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. | Percentile | Lag (detection to ticket) | | ------------------- | ------------------------- | | p50 | 1.4 seconds | | p75 | 4.2 seconds | | p90 | 12.8 seconds | | **p95 (this card)** | **47 seconds** | | p99 | 38 minutes | | max | 4 hours 12 minutes | 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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/atlassian-token-expiry-imminent)), rate-limit exhausted ([Rate-Limit Exhausted](/nerve-centre/kpi-cards/jira/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 | Card | Why pair it with Finding-to-Ticket Dispatch Lag | What the combination tells you | | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | [Critical Findings Without a Jira Ticket](/nerve-centre/kpi-cards/jira/critical-findings-without-a-jira-ticket) | The hard-failure side. Lag is degrading; this is when degradation tips into outage. | Lag rising for 24h then this card going non-zero is leading-then-lagging, dispatch was slow then stopped. | | [Atlassian Token Expiry Imminent](/nerve-centre/kpi-cards/jira/atlassian-token-expiry-imminent) | Most common cause of lag spikes. | If both fire, rotate the token; lag returns to baseline within minutes. | | [Rate-Limit Exhausted](/nerve-centre/kpi-cards/jira/rate-limit-exhausted) | Second-most-common cause. | If both fire, throttle-back the dispatch rate or upgrade the Atlassian plan. | | [API Rate-Limit Headroom](/nerve-centre/kpi-cards/jira/api-rate-limit-headroom) | Real-time leading indicator. | Headroom \<30% predicts p95 dispatch lag rising; address before this card fires. | | [VortexIQ Findings Open](/nerve-centre/kpi-cards/jira/vortexiq-findings-open) | Downstream count. | Lag rising plus open count climbing equals queue building because ingestion is slowing, not because the team is slowing. | | [Open Tickets](/nerve-centre/kpi-cards/jira/open-tickets) | Total Jira queue. | Helps separate Vortex IQ-specific dispatch issues from generic Atlassian-side latency. | | Cross-connector: [Datadog API Error Rate](/nerve-centre/datadog/dd_api_error_rate) | Adjacent connector latency / error peer. | Multiple connector lags rising together points to network or Vortex IQ infrastructure, not Atlassian-specific. | | Cross-connector: [GitHub Action Dispatch Lag](/nerve-centre/github/gh_workflow_lag) | Same pattern, different tracker. | Cross-tracker dispatch latency benchmark; Atlassian and GitHub typically run within an order of magnitude of each other. | ## 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:** | Reason | Direction | Why | | ------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Time zone display** | Either | Jira's UI shows ticket `created` in user-local TZ; Vortex IQ stores in UTC. A spot-check made without TZ-normalising can look wildly wrong. | | **Sampling vs full population** | Spot-check noisier | A single spot-checked finding tells you nothing about p95; only an aggregate over 30 days is meaningful. Don't base a verdict on one ticket. | | **Replay / backfill writes** | Spot-check overstated | If Vortex IQ replays a missed finding (e.g. after a backfill), the `detected_at` is the original detection moment but the `created_at` is the replay moment, lag looks high. The aggregate p95 excludes replays via a `is_replay = false` filter. | | **Manual ticket creation** | Excluded | Tickets created manually in Jira (without Vortex IQ dispatching) are excluded from this metric, they have no audit-finding pair. | | **Polling jitter** | Sub-second noise | Vortex IQ's audit detection runs in a 60-second poll loop; the `detected_at` timestamp resolves to the poll instant, not the underlying-event instant. Adds \<60 sec noise at the floor. | **Cross-connector reconciliation:** | Card | Expected relationship | Causes of legitimate divergence | | ---------------------------------------------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`github.gh_workflow_lag`](/nerve-centre/github/gh_workflow_lag) | Same dispatch-latency pattern, different vendor. | Atlassian and GitHub APIs have different rate-limit shapes; absolute numbers are not comparable, but trend direction often correlates if the cause is Vortex IQ-side. | | [`datadog.dd_api_error_rate`](/nerve-centre/datadog/dd_api_error_rate) | Connector-side latency / error peer. | Datadog rising while this card holds equals connector-specific issue; both rising together equals broader Vortex IQ-side or network issue. | | [`audit_finding` registry](/nerve-centre/INDEX) | This card's domain. | Findings in the registry without a corresponding Jira ticket pair are excluded from the lag computation but counted in [Critical Findings Without a Jira Ticket](/nerve-centre/kpi-cards/jira/critical-findings-without-a-jira-ticket). | ## 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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/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](/nerve-centre/kpi-cards/jira/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.