How to Detect and Alert on Silent Supplier Import Failures

AEO answer: Detect silent import failures by monitoring row counts against expected volume, tracking field-completeness and error rates per run, and setting alerts when an import returns zero or unusually low changes. Gating imports behind a validation step before publishing prevents bad or incomplete supplier data from reaching your live storefront.

A scheduled supplier import ran last night. The log says “completed.” No red text, no exception, no email in your inbox. Everything looks fine, right up until someone notices that half the catalog still shows last month’s prices, or three thousand products are quietly missing images. Nobody caught it because the import did not fail in a way any system was watching for. It just did less than it was supposed to, and nothing flagged that as a problem.

That is the failure mode that hurts most, not because it is dramatic, but because it is invisible. A crashed import gets noticed fast: someone checks the log, sees an error, fixes it. A silent failure can run “successfully” for weeks before anyone connects the dots. This guide covers why these failures go unnoticed, what to monitor to catch them early, how to alert on them without drowning in noise, and what to do once bad data has already reached the storefront.

This guide covers scheduled, batch supplier imports. If real-time, webhook-driven channel inventory sync is the problem instead, see Why Isn’t My Inventory Syncing in Real Time?.

Why Import Failures Often Go Unnoticed

Most import pipelines are built to detect hard failures: a connection timeout, a malformed file, an authentication error. Those produce a clear exit code and a clear log entry, and most monitoring is wired to catch exactly that. The problem is that most real-world supplier import failures do not look like failures from the pipeline’s point of view.

An import that fetches an empty file because the supplier’s export job failed on their end will often complete successfully. Zero rows is a valid response, not an error. An import that processes 200 records out of an expected 5,000 because the supplier sent a partial file will also complete successfully. The pipeline did what it was told: fetch, parse, write what is there. Nothing throws an exception when “what is there” is far smaller than “what should be there.”

That is a class of runs that are technically successful and practically broken. If your only signal is the exit code, you will miss every one of them. Catching this category means monitoring the content of what an import did, not just whether it ran.

Common Causes of Silent Import Failures

A handful of scenarios account for most silent failures in recurring supplier feeds:

• The supplier’s own export failed. What lands at the URL or FTP path you poll is an empty file, a truncated file, or the previous day’s file served again from a cache.
• A partial file from an interrupted export. The supplier’s job was killed partway through, so you receive real data, just far less of it, with nothing indicating the file is broken.
• An auth change returning a valid-looking empty response. Some APIs return 200 OK with an empty array when a token expires, rather than a 401. The request “succeeded,” it just returned nothing.
• A schema change that silently drops a field. A supplier renames a column, and your mapping quietly ignores the one it doesn’t recognize. Every product imports, but a required field is empty for all of them.

None of these trigger a connection error or a parse error. Each produces a run that looks clean and is wrong underneath. If you are automating recurring supplier imports from more than one source, this is exactly the failure category the pipeline needs to account for. The fix is not more retries, it is watching the actual output of each run.

What to Monitor: Row Counts, Error Rates, Field Completeness

Three metrics catch the overwhelming majority of silent failures, and none require complex tooling, just recording them on every run: row counts against a trailing baseline, error rate per run, and field completeness for the fields your catalog depends on. A run that returns 80 products when the supplier reliably sends 4,000-4,500 is a broken export; a run where price drops from 100% populated to 4% “succeeded” but is unusable.

For the complete field-by-field logging spec, see Automating Recurring Supplier Imports Into Your Product Catalog. This section focuses on the metrics that catch a reported-success-but-actually-broken import: field-completeness drift and row-count trend deviation, not just pass or fail.

Field completeness is the one that catches a silent schema change immediately, because a dropped field shows up as a completeness drop while the row count stays normal. Row-count deviation is best expressed as a percentage threshold against the trailing average rather than a fixed number, so it adapts to a supplier whose volume naturally shifts week to week.

Setting Up Alerts for Failed or Partial Imports

Numbers nobody looks at are no different from not monitoring at all. The metrics above only matter if they trigger a notification when they cross a meaningful threshold.

A workable policy has two tiers. The first is immediate: zero rows returned, row count under half the trailing average, or error rate past a defined ceiling. These justify an email, Slack message, or webhook the moment they happen, because the run should not be trusted to publish as-is.

The second tier is lower urgency: completeness dipped for a non-critical field, or a new, unmapped column appeared. These fit a daily digest rather than an interruption, since they typically need someone to review the mapping before the next run, not an emergency response.

The alert needs to say something specific. “Import failed” is not actionable. “Supplier X returned 340 rows, expected ~4,200 (92% below average)” tells you exactly what to check. If imports run on a recurring schedule, cron-based scheduled imports are the natural place to attach this monitoring. MicroPIM’s automation features let you attach conditional alerts directly to scheduled runs, so a feed that returns nothing or returns garbage gets flagged before anyone assumes it went fine.

Preventing Bad Data From Reaching Your Storefront

Alerts tell you something went wrong. They do not, by themselves, stop bad data from reaching customers before someone reads the alert. That takes a gate between “the import ran” and “the catalog is live,” not just a notification running in parallel with publication.

The reliable version of this gate is a validation step that has to pass before an import’s changes reach published records. If row count, error rate, or completeness on a run falls outside acceptable bounds, the run is held for review instead of written straight through. That is a meaningfully different design from “import, then alert,” because it moves the check before the damage instead of after it.

This works alongside, not instead of, filtering rules that catch specific unwanted records regardless of whether the overall run looks healthy. A validation gate catches a run that is broken as a whole; a rule-based filter catches individual records that should never be imported, like a discontinued SKU a supplier keeps re-sending. Combining smart filtering rules on import with run-level validation covers both cases. See the import documentation for how validation and mapping apply before data is committed.

Building a Simple Import Health Dashboard

A dedicated observability platform is not required here. A single view listing every scheduled supplier source, its last run time, row count against the trailing average, error rate, and field completeness catches most problems at a glance, sorted by risk rather than alphabetically. A feed that ran on schedule with normal numbers needs no attention; a feed that is late or shows an unusual row count or error spike belongs at the top.

Pair this with a per-run audit trail recording exactly what changed, not just aggregate counts. When a dashboard flags a run as unusual, the next question is always “what specifically changed.” MicroPIM’s audit log tracks every change an import made, turning “the error rate spiked” into “these 340 records lost their price field.”

Recovery: Rolling Back a Bad Import

Even with monitoring and validation gating in place, a bad import will occasionally reach the catalog. A rollback path needs to answer two questions fast: which records the run touched, and what their values were immediately before. A per-run change record makes that close to instant instead of a guessing game between the bad import and legitimate edits made in the same window.

For the full rollback versus partial-commit decision framework, see Automating Recurring Supplier Imports Into Your Product Catalog. This section covers recovery specifically for imports that silently degraded rather than hard-failed. Once affected records are identified, treat the incident as a prompt to tighten the thresholds that should have caught it earlier.

Frequently Asked Questions

How do I know what row count to expect before I can alert on deviations? Use the trailing average from recent successful runs rather than a number you guess up front. After four or five normal runs you have a baseline, and the threshold should be relative, a drop of more than 30-40% from that average, rather than absolute, since supplier volume naturally shifts.

Is a partial import ever acceptable, or should every incomplete run be blocked? It depends on whether the import is additive or a full-snapshot replacement. A partial file that only adds new products is usually low-risk with a flag. A partial file used as a full-snapshot replacement is dangerous, because missing records are often read as no-longer-available, which can silently unpublish valid products.

What is the fastest way to catch a silent failure with no monitoring set up yet? Start with row count alone. It is the cheapest signal to implement and catches the most common pattern: an empty or near-empty file from a broken supplier export. Add error-rate and completeness tracking once row-count alerting is proven reliable.

Catching a silent import failure after it reaches the storefront costs far more than catching it in the run itself. MicroPIM tracks row counts, error rates, and field completeness on every scheduled supplier import, gates publication behind validation, and logs every change so a bad run can be traced and reversed quickly. Start your free trial at app.micropim.net and set up monitored, alerting imports for your first supplier feed today.