Slow Searches During Checkout Window (5m), table

​

At a glance

This table lists the individual slow Elasticsearch searches that occurred inside a live checkout window over the last 5 minutes, and pairs that count against any drop in checkout conversion on the connected storefront. It exists because not all slow searches are equal: a slow query at 3am against an internal report is a curiosity, but a slow search while shoppers are trying to find and buy is money walking out the door. The card joins the search slowlog to the checkout funnel so you can see, in one place, whether slow search is co-occurring with shoppers failing to complete purchases. The alert fires when more than 5 slow searches coincide with a measurable checkout drop in the same window, because that conjunction is the strongest available signal that search latency is directly costing conversions right now.

​

Calculation

slow_searches = searches in last 5m where took >= slowlog_threshold
                 (default slowlog warn/info threshold, commonly 1s)
checkout_window = periods in last 5m with active checkout sessions
in_window      = slow_searches whose timestamp falls in checkout_window
checkout_drop  = conversion(this 5m) < conversion(rolling baseline)

ALERT if  count(in_window) > 5  AND  checkout_drop is true

​

Worked example

1. Spot the dominant query shape. Three of the six slow rows are the same expensive pattern: a filtered facet search with 8 aggregations. That is the heavy query, and it is firing at peak traffic exactly when shoppers are deepest in the funnel.
2. Connect latency to abandonment. The checkout drop of 0.9 percentage points coincides precisely with the slow-search burst. Shoppers who searched mid-checkout waited nearly 2 seconds for results; a meaningful share bounced rather than waiting.
3. Quantify the exposure. At this traffic level the 0.9pp conversion drop maps to lost orders that are directly attributable to the window, not a vague “search feels slow” complaint.

Revenue framing (illustrative):
  - Checkout sessions in the 5m window: ~640
  - Baseline conversion: 3.1%  ->  ~20 orders expected
  - Observed conversion: 2.2%  ->  ~14 orders
  - Shortfall: ~6 orders in 5 minutes co-occurring with slow search
  - Average order value £48  ->  ~£288 at risk in this single window
  - If the heavy query persists across the peak hour, the figure compounds

4. Remediate. Short term, the team caps the expensive aggregation query (reduces facet count, adds a request cache, or routes it to a dedicated node). Conversion recovers toward baseline in the next window and the alert clears. Long term, they pre-compute the heavy facets or add a filter cache so the query never crosses 1s at peak.

1. Co-occurrence is the whole point. Slow searches alone do not prove harm and a checkout dip alone does not prove search caused it. The card only raises an alarm when both happen together, which is the closest you get to a causal signal without a controlled experiment.
2. The table tells you what to fix, not just that something is wrong. Because it lists the actual slow queries, you can see the offending query shape immediately (here, an 8-aggregation facet search) rather than guessing.
3. Timing within the funnel is everything. The same slow query at 3am would not fire this card. It fired because it happened while real shoppers were trying to buy. That is why this is a Revenue-at-Risk card and not a generic latency card.

​

Sibling cards

​

Reconciling against the source

The search slowlog is the primary source. It is configured per index via index.search.slowlog.threshold.query.warn (and .info, .debug, .trace); the logged entries land in the slowlog file/index and contain the query text, took time, and index. Confirm the threshold matches the 1s the card assumes. GET /<index>/_settings?include_defaults=true&filter_path=**.slowlog confirms the active slowlog thresholds for the product index. GET /<index>/_stats/search gives query_time_in_millis and query_total so you can corroborate that average latency rose in the window. On the storefront side, reconcile the checkout-drop half against the platform’s own funnel report (Shopify checkout/conversion analytics, BigCommerce analytics, or Adobe Commerce reports) for the same 5 minutes.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre