At a glance
The gap between how many product documents your MongoDB collection holds and how many products your live ecommerce catalogue actually has. Many merchants store their full product catalogue in MongoDB (as a fast read store, a search index source, or a custom storefront backend) and sync it from the commerce platform. When those two counts diverge, the sync has failed: products exist in one system but not the other. This is a MongoDB-distinctive cross-platform check, because the database holding a parallel copy of the catalogue is exactly the pattern where silent drift costs sales. The card alerts on >0 drift: any difference at all means the systems are out of step.
Calculation
This is a cross-platform reconciliation card: it takes one count from each system and reports the difference.mongo_countis the number of product documents in the configured collection. For large collections the engine can useestimatedDocumentCount()(which reads collection metadata and is near-instant) orcountDocuments()with a filter (which is exact but scans). The choice and any scope filter are part of the connector configuration.ecom_countis the authoritative product count from the commerce platform: what the storefront actually sells.driftis the signed difference. A positive drift means MongoDB has more documents than the catalogue (stale products that were deleted upstream but never removed, or duplicates). A negative drift means MongoDB is missing products the catalogue has (a sync that failed to insert new products).
- Definitions must match on both sides. The counts are only comparable if both systems count the same thing: product-level vs variant-level, and the same status scope (active only, or active plus draft). A constant non-zero drift that never changes is usually a definition mismatch, not a sync failure.
- The alert is zero-tolerance by design. Unlike a performance gauge with a percentage threshold, a catalogue sync is meant to be exact, so the meaningful signal is “any drift at all”. The 24-hour baseline distinguishes a new drift (sync just broke) from a persistent one (definition mismatch to be reconciled once).
- This is the MongoDB-distinctive case. The check exists because the database is holding a parallel copy of the catalogue. The whole risk is that the copy silently goes stale while the storefront keeps reading from it.
Worked example
A platform team runs a custom storefront that reads product data from a MongoDBproducts collection, kept in sync from BigCommerce by a nightly sync job plus a webhook for live changes. Readings taken on 14 Jun 26.
At 02:00 the nightly job has just run and the two counts match exactly: zero drift, healthy. By 09:30 the merchandising team has added 55 new products in BigCommerce for a launch, but those products have not appeared in MongoDB, so drift is -55. The card fires immediately. By 11:00 the drift has not closed on its own, which proves the live webhook sync (not just the nightly job) is broken: the new products will not appear on the custom storefront until someone fixes it, so 55 sellable products are invisible to shoppers.
At 14:00 someone runs a manual reimport to fix it, but the import inserts the 55 new products without de-duplicating against the existing set, so now MongoDB has 55 too many: drift flips to +55. The sign of the drift told the operator exactly what happened at each step.
- Negative drift (missing products): the sync pipeline failed to insert. Check the webhook delivery log and the sync job’s error output, then reconcile by re-running the sync for the affected products. The business impact is immediate: those products cannot be sold on the MongoDB-backed surface.
- Positive drift (extra products): the sync failed to delete upstream-removed products, or a reimport created duplicates. The risk is showing discontinued or duplicate products to shoppers. Reconcile by removing the orphaned documents, ideally with a sync job that deletes documents absent from the source.
- Zero drift is the only healthy reading for a synced catalogue. Any persistent non-zero value means the database copy and the storefront disagree about what is for sale, which is a revenue and trust problem.
- The sign tells you the failure mode. Negative means missing inserts (lost sales); positive means failed deletes or duplicates (showing the wrong products). You do not need to investigate blind: the sign points you at the right half of the pipeline.
- A constant non-zero drift is usually a definition mismatch, not a live failure. If the gap never moves and equals, say, your exact count of draft products, the two systems are simply counting different scopes. Align the definitions once, then a non-zero value genuinely means a broken sync.
Sibling cards to read alongside
Reconciling against the source
Where to confirm the number in MongoDB’s own tooling:Why our number may legitimately differ from the native view:mongosh:db.<collection>.countDocuments({})gives the exact count with any filter you apply;db.<collection>.estimatedDocumentCount()gives the fast metadata-based count. Use the same scope filter the connector uses to reproduce the MongoDB side.db.stats()/db.<collection>.stats(): thecountfield gives a quick (estimated) document count for the collection without a full scan. Atlas: the Collections browser shows the document count per collection in the data explorer. Ecom side: the connected commerce platform’s own admin (Shopify, BigCommerce or Adobe Commerce) holds the authoritative product count this card subtracts against; check it under the platform’s product / catalogue listing.
Cross-connector reconciliation:
Known limitations / FAQs
Why does the card alert on any drift at all, instead of a percentage threshold? Because a catalogue sync is supposed to be exact. A performance gauge tolerates small fluctuations, but a synced product collection either matches the source or it does not, and any mismatch means products are wrong somewhere. A zero-tolerance alert catches the failure the moment it happens rather than waiting for it to grow large enough to cross a percentage line, by which point shoppers may already be seeing missing or stale products. If a small constant offset is expected because of a definition difference, fix the definition rather than raising the threshold. What does the sign of the drift tell me? The sign points directly at the failure mode. A negative drift (MongoDB has fewer documents than the catalogue) means the sync failed to insert: new products exist upstream but never made it into MongoDB, so they are invisible on the MongoDB-backed surface, which costs sales. A positive drift (MongoDB has more) means the sync failed to delete upstream-removed products, or a reimport created duplicates, so shoppers may see discontinued or repeated products. Reading the sign saves you investigating the wrong half of the pipeline. I have a constant drift that never changes. Is my sync broken? Probably not; a constant, unchanging drift is almost always a definition mismatch rather than a live failure. The usual causes are granularity (one side counts products, the other counts variants) and status scope (one side includes draft or archived products, the other excludes them). Confirm by checking whether the drift equals a known category, such as your exact number of draft products. Align the two definitions once, after which a non-zero drift genuinely indicates a sync problem. Does usingestimatedDocumentCount() make the number unreliable?
The estimate reads collection metadata and is near-instant, which is why it is preferred for very large collections, but it can lag for a short window immediately after bulk inserts or deletes because the cached metadata has not caught up. For routine monitoring this is fine. If you see a small transient drift right after a big sync that resolves on its own within minutes, the estimate catching up is the likely cause. For an authoritative figure during reconciliation, use the exact countDocuments().
My MongoDB-backed storefront falls back to the commerce platform for unknown products. Does drift still matter?
It matters less for availability but still matters for performance and correctness. A fallback means a missing product is still sellable, but every request for it bypasses the fast MongoDB read path and hits the slower commerce API, which adds latency and load. Positive drift (stale extras) is worse in this setup because there is no fallback to correct a product that should no longer exist: the storefront will keep showing it. Treat drift as a real defect even with a fallback in place.
How do I safely fix a positive drift (too many documents)?
Carefully, because the fix is a delete. First confirm a recent successful backup exists (see Last Successful Backup (hours ago)). Then identify the orphaned documents (products in MongoDB whose IDs no longer exist in the commerce catalogue) rather than deleting blindly by count. The durable fix is a sync job that reconciles both directions: it inserts products missing from MongoDB and removes documents whose source product has been deleted, so positive and negative drift both self-heal on the next run.