The report opens on 38 items that failed outright and 412 that uploaded with something Meta did not like, and the Advantage Plus campaign they belong to is having a normal week. So which lines do you fix before lunch? And does any of it explain last Thursday, when ROAS halved for 2 days and then recovered on its own?

Every feed guide answers the first question with a list of named errors. The second one is where the money is.

Short answer: Meta catalog feed errors come in two states, item-level and feed-level, and the report names both. It cannot name the third state, which is a feed that uploaded cleanly and then went stale. Rank the named errors by the revenue of the items behind them, and read the next-update clock before you read the error count.

The takeaways

The report describes one upload event. A green report from Tuesday says nothing about what your catalog serves on Friday.
A partial failure is the expensive one. It leaves every campaign running and quietly shrinks the pool of items your budget pushes through.
No ad metric can see this. CTR, ROAS and CPM all move in the shape of a creative problem, so the check belongs on the feed side.

What does Meta's feed error report leave out?

Everything that happened after the last upload. The report covers one ingest event and stops there. AdNabu's writeup of Commerce Manager splits that event into two outcomes: "Items failed to upload", where some products were rejected and the rest went through, and "Feed upload failed", where the whole file was blocked. Both sit under Data Sources, where AdNabu also documents a Download Issue Report button under the Next Update field.

A receipt is not a health check. The distinction sounds pedantic until it costs you a week: a report can be green because everything is correct, or green because nothing has been attempted since the last good run. Same colour, two different catalogs.

Which feed errors are worth fixing first?

The ones attached to items you sell. That reads as obvious and almost nobody does it, because the report is organised by error type, which is the wrong axis. 400 rejections on long-tail SKUs that move 2 units a month cost you close to nothing. Three rejections on the products carrying your revenue cost you the quarter.

So the triage is a join rather than a reading exercise. Pull the affected item IDs out of the issue report, sit them next to your own sales data, and sort by what those items earned last month. The first time I did this on a 9,000-item catalog the useful part of the list was 4 SKUs, and the rest was weeks of diligent work for no return.

Why does a clean error report still serve the wrong price?

Because the catalog is a copy of a file, and copies age. Koongo's guide puts it plainly: "Facebook does not read your product prices directly from your webshop. Instead, it reads from a product feed", and "the gap between your store and your Facebook catalog can be minutes or days, depending on your setup". Koongo also states Facebook's own recommendation as updating that file at least once every 24 hours.

Now add a failure. If the scheduled fetch cannot reach your file, the catalog does not empty out. It freezes, and keeps serving the last version it ingested, which is exactly what a healthy catalog does between fetches. From inside Ads Manager the two look identical, and the report says nothing about either, because no upload happened for it to report on. If the field you are chasing is availability, the sold-out case has its own post: out of stock products in catalog ads.

What does a partial feed failure do to delivery?

It changes the denominator. Say 400 items normally qualify and a malformed column knocks out 60 of them. Your budget does not shrink to match. The same daily spend now pushes through 340 products, frequency per item climbs, and over a few days the CTR curve bends in the shape everyone reads as creative fatigue.

Marpipe's troubleshooting guide names it well: "Product feed errors don't always trigger red alerts. Sometimes it's subtle like an outdated inventory flag that kills a top seller." Subtle is the whole difficulty. A total failure is loud and somebody catches it by lunchtime. A partial one leaves the campaigns running and every metric plausible, and the only trace is the count of eligible items, a number almost nobody charts. Reading that count as a diagnosis is its own job, which I worked through in Meta catalog campaign performance dropped.

Why won't a ROAS rule catch a feed problem?

Because a rule reads the ad layer and the fault sits one layer below it. Adscalr's rules fire on 8 ad metrics (CPI, CTR, hook rate, hold rate, ROAS, spend, frequency, CPM), the only actions are pause and kill, and every evaluation is logged. A stale feed is invisible to all 8 by construction. Adscalr does not read or monitor product feeds, and I would rather say so plainly.

There is a worse version. The rule does eventually fire, and it fires correctly on bad information. ROAS did fall. The ad set gets paused, the bleeding stops, and the fault underneath carries on being true. You have automated a symptom. The safeguards around a kill (the learning-phase lockout, a ROAS floor, a 30-minute undo window) protect an ad from a bad decision. None of them protect a decision from a bad input.

What is the minimum daily feed check?

Three numbers and one click, about 5 minutes. First, the timestamp of the last successful fetch in Commerce Manager: if it is older than twice your scheduled interval, treat everything downstream as unverified. Second, total item count against yesterday. Third, in-stock count against yesterday. Any of those moving more than roughly 10% overnight, with no sale or restock behind it, is a feed event rather than a merchandising one.

Then the click. Open one live ad, go through to the product page, and check that the price and the availability agree. That is the only step that catches a file which arrived on time and was wrong, which is why I still do it by hand. You are watching a clock, not an error count, and the clock is the part the report was never built to show you.

Automation earns its place once the inputs can be trusted. Automation and alerts watches the spend and keeps a bad pause reversible, while the freshness of the file stays with you and your shop integration. Get the second one right and the first starts telling the truth.

Meta catalog feed errors: what to fix first