Slow Ops During Checkout Window (5m), MongoDB

​

At a glance

The count of MongoDB operations that breached the slow-query threshold (default slowms of 100ms) inside the same rolling 5-minute window in which the storefront’s checkout conversion dropped. This is a join card, not a raw database metric: it correlates the database profiler’s slow-op stream against the ecommerce connector’s checkout funnel. One slow find on a product page is noise; five slow ops landing in the exact window the checkout success rate fell off a cliff is a causal story. This card exists to answer the only question that matters during an incident: “Is the database why people stopped buying?”

​

Calculation

1. Detect the checkout-drop window. The linked storefront connector reports a rolling checkout conversion rate (orders / checkout-started sessions) per 5-minute bucket. A window is flagged when the current bucket falls materially below the trailing baseline for the same time-of-day and day-of-week. The database is not consulted in this step; the symptom is defined entirely storefront-side.
2. Pull the slow ops for that exact window. For every flagged window, the engine reads MongoDB profiler entries where millis > slowms and ts falls inside the window. The default slowms is 100ms; the card honours whatever the instance is actually configured to, read from db.getProfilingStatus(). Each entry keeps ns, op, millis, docsExamined, nreturned, planSummary, and appName.
3. Join, count, rank. Slow ops are bucketed into their window, counted, and sorted by millis descending. The headline is the count; the table is the ranked detail. The alert fires when count > 5 for a window that is also flagged as a checkout drop.

​

Worked example

• Five of the seven ops are full collection scans (COLLSCAN) on shop.inventory_levels, each examining roughly 412,000 documents to return a single one. That is the textbook signature of a missing or dropped index.
• The docsExamined : nreturned ratio of 412,005 : 1 is the smoking gun. A healthy IXSCAN lookup on a single stock record should examine 1 to a handful of documents, not the whole collection.
• The two IXSCAN ops (cart_validation, pricing_rules) are slow but proportionate; they are collateral, slowed by the same CPU and cache pressure the scans are causing, not the root cause.

Attributing the revenue loss for this 5-minute window:
  - Baseline conversion (same slot, trailing 4 weeks):  71%
  - Observed conversion during window:                  38%
  - Started-checkout sessions in window:                240
  - Expected orders at baseline:    240 x 0.71  = ~170
  - Observed orders:                240 x 0.38  = ~91
  - Lost orders in this 5 min:      ~79
  - Average order value:            £64
  - Estimated lost revenue (5 min): 79 x £64    = ~£5,056

1. The join is the value. Either signal alone is ambiguous. Slow ops during a quiet hour are a tuning backlog item. A checkout drop during a payment-gateway wobble is not a database problem. The intersection in time is what turns a vague “the site felt slow” into “these five COLLSCANs on inventory cost us roughly £5k in five minutes”.
2. Read the plan summary first. COLLSCAN in a checkout window is almost always a missing index or a query that stopped matching its index. IXSCAN ops that are slow point at cache pressure, lock contention, or genuinely large result sets, a different fix.
3. The docsExamined : nreturned ratio is the diagnostic. A ratio near 1:1 means the index is doing its job. A ratio in the hundreds of thousands to one means you are scanning a collection to find a needle. That ratio, not raw millis, is what you take to the engineer who shipped the migration.

​

Sibling cards to reference together

​

Reconciling against the source

Database profiler. Run db.setProfilingLevel(1, { slowms: 100 }) then query db.system.profile.find({ millis: { $gt: 100 }, ts: { $gte: <window-start>, $lt: <window-end> } }).sort({ millis: -1 }) for the same window. This is the exact source the card reads; the rows should match one for one. Slow-query log. When profiling level is 0, MongoDB still writes ops slower than slowms to the diagnostic log (mongod.log). Grep for Slow query lines with the window timestamps to cross-check. db.currentOp(). For ops still running at snapshot time, db.currentOp({ "secs_running": { $gte: 1 } }) shows live long-runners that the profiler will record once they complete. Atlas Profiler / Query Insights. On MongoDB Atlas, the Performance Advisor and Query Profiler views surface the same slow ops with suggested indexes; the Atlas charts let you scrub to the exact 5-minute window.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre