Latency on the checkout service overlaid with order volume, when checkout slows, sales follow.
At a glance
A dual-axis chart overlaying checkout-service p95 latency from Datadog with orders-per-minute from the connected commerce sibling (Shopify, BigCommerce, Adobe Commerce). For a merchant, this is the visual answer to “does my checkout service speed actually affect sales?” Spoiler: yes, and this card lets you see the moment latency rises and orders fall.
Calculation
Calculated automatically from your Datadog 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 specialty foods brand on BigCommerce running Datadog APM on the checkout service. 24-hour view captured on 23 Apr 26.
Apdex on the checkout service dropped from 0.92 to 0.78 during the slowdown. The orders/min curve dropped 50% (14 to 7) during the same window. The temporal pattern was: latency rose first, orders fell 10-15 minutes later. This is the typical lag between “shoppers experience slowness” and “shoppers abandon”.
- The lag between latency rising and orders falling is real and measurable. Shoppers do not abandon instantly; they retry, refresh, switch tabs. The lag is typically 5-15 minutes for desktop and 2-8 minutes for mobile. Action: if you see latency rising on this card, the orders/min curve will follow. Do not wait for orders to drop to confirm; latency is the leading indicator.
- The dual-axis visualisation makes the causal link unmistakable. Two separate charts of latency and orders would require the engineering team to mentally overlay them; the dual-axis chart shows the inflection points side-by-side. The first time a merchant sees this card during a real incident, they typically have a “click” moment of “I see the relationship now”.
- Latency above 3,000 ms during peak hours costs more than during off-peak. This brand had latency briefly hit 1,500 ms at 22:00 EST a few weeks earlier with no detectable revenue impact (low traffic, slack capacity). The same latency at 13:00 (peak) cost real money. The card’s peak-hours alert threshold reflects this asymmetry.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Datadog:APM → Service: checkout for the latency time-series of just the checkout service. APM → Service Map filtered to checkout for upstream/downstream visibility. Dashboards → Custom dashboard combining checkout latency with imported commerce data (Shopify/BC/Adobe webhooks landing in Datadog).The orders/min side of this card comes from the connected commerce platform’s KPI; open that platform’s order analytics for the same window. Why our values may legitimately differ from a hand-aligned chart:
Cross-connector reconciliation (this is the entire point of this card):
Known limitations / merchant FAQs
Why is this card cross-platform? Because it joins data from two different connectors: Datadog (latency from APM) and the commerce platform (orders/min). The “cross” in cross-platform refers to the type of data, not multiple checkout services. This is one of the most powerful patterns Vortex IQ enables: the cause-and-effect link between technical performance and business outcomes is invisible inside any single tool but obvious when their data is overlaid. My checkout service is named differently, e.g.payment-api or commerce-checkout. Does the card still work?
Yes, but you need to configure the service name. Open Vortex IQ Settings → Datadog → Service mapping and set the merchant’s checkout service name. The default is service:checkout; once you change it, the card reads from the correct service.
My commerce platform is not connected. What does the card show?
The card displays “Connect a commerce platform to enable this card”. This card requires both Datadog (for latency) and a commerce sibling (for orders/min) to function. Without orders/min, the dual-axis is incomplete and the card is hidden.
The latency line is up but orders are stable. What does that mean?
Three possible interpretations: (1) The traffic mix has shifted to lower-conversion sources (paid social brings high traffic but low conversion), so orders/min is artificially low from the upstream side; (2) The latency rise is on a non-conversion-blocking endpoint (e.g. saved-address autocomplete) where shoppers can still complete checkout despite slowness; (3) Shoppers are tolerating the slowness, possibly due to high purchase intent or unique products. Combine with Conversion Drop During Incidents to confirm.
The orders line is up but latency is also high. Is the card wrong?
Two scenarios: (1) Promotional traffic spike where unusually high purchase intent overrides slowness; (2) Cached responses make some checkouts feel fast even when the back-end is slow. The card is right; the relationship between latency and orders is not perfectly linear. Use longer time windows to see the underlying trend.
Why peak hours and not 24/7 alerting?
Because off-peak slowness during overnight or low-traffic hours has minimal revenue impact. A 3,000 ms p95 at 03:00 EST when 2 orders/min are happening costs almost nothing; the same latency at 14:00 EST when 14 orders/min are happening costs significant revenue. Peak-hours-only alerting reduces false-page noise during low-impact windows.
Datadog says checkout is healthy but orders are dropping.
The classic Datadog blind spot. Three causes: (1) The bottleneck is in a third-party widget the APM does not instrument (payment iframe, fraud check, address-validation API); (2) The bottleneck is browser-side (slow JS execution); (3) The bottleneck is upstream (CDN or payment-PSP). Open Page Load p95 (RUM) and Critical-Path Tests Status to see customer-side measurements.
My Logs API returns 400 No valid indexes. Does this card still work?
Yes. This card uses APM (Metrics API) and the commerce-sibling Order KPI; both are independent of Logs.
Why is the card showing 24h and not 7-day?
Because the relationship between latency and orders is most legible at high-resolution windows (1-minute buckets over 24 hours). A 7-day window would compress the temporal pattern too much; the inflection points where latency rises and orders fall would blur. For longer-term trends, use the platform-specific cards individually.
Can I customise the alert threshold per merchant?
Yes. The default 3,000 ms p95 during peak hours is calibrated for typical merchants. Some brands tolerate higher latency (luxury, custom-furniture, B2B); others need lower (high-velocity discount, fast-fashion). Adjust in Settings → Datadog → Alert Thresholds → Checkout Service Health.