A scheduled job that finishes cleanly while doing nothing is the hard case. There is no exception to catch, no alert to configure, and every dashboard you own reports a successful run. Mine did exactly that for eight days: eleven affiliate feeds, one of them importing zero rows every morning, exit code 0 every time. If you want the incident itself, I wrote it up separately: My pipeline ran green for 8 days while importing nothing.

This post is the other half. Three checks I added afterwards, why each exists, and where they belong in the schedule. They are small, they have no dependencies, and together they close the gap between "the script finished" and "the script worked".

1. Measure freshness, not success

Start here. This is four lines of SQL and it is the single highest-value check in any scheduled import.

Your job writes rows. Those rows carry a timestamp. So instead of asking whether the run succeeded, ask how old each source's newest row is:

SELECT source,
       MAX(last_seen) AS newest,
       COUNT(*)       AS rows
FROM   items
WHERE  active = 1
GROUP  BY source;

Run that after every import and compare each result against your cron interval. A source that is suddenly days behind the others has stopped importing, whatever the exit code said. In my case ten sources showed yesterday and one showed eight days ago, across 1126 rows. That one query was the entire diagnosis.

Wrapped up:

from datetime import timedelta
from feed_guard import check_freshness

stale = check_freshness(
    cursor,
    table="items",
    source_column="source",
    seen_column="last_seen",
    max_age=timedelta(days=2),
    where="active = 1",
)

for s in stale:
    log.error("stale source: %s", s)

Set max_age comfortably above your cron interval so a single skipped run does not page you, but tight enough that a genuinely dead source shows up the next day.

The reason this works where exception handling does not: it measures the outcome rather than the process. A parser can run to completion, log nothing, and write nothing. The timestamp cannot lie about that.

2. Count what you skip

Every continue in a parse loop is a silent discard. Most pipelines have several, and none of them are counted.

Mine began with a country filter. The feed used to say Nederland and changed to NL, so every product hit continue on the first line of the loop. The parser ran over 1887 products, discarded all 1887, and reported success.

Had I been counting discards by reason, the log would have said so on day one:

from feed_guard import SkipCounter

skips = SkipCounter()

for product in feed:
    if product.get("country") not in NL_CODES:
        skips.skip("country not NL")
        continue
    if not product.get("id"):
        skips.skip("no id")
        continue
    write(product)
    skips.kept()

log.info(skips.report())
# seen=1887 kept=0 skipped=1887 (100%) | country not NL=1887

That line is the alert. You do not need a monitoring stack to act on it:

if skips.looks_broken():
    raise RuntimeError(f"parser discarded almost everything: {skips.report()}")

The rule of thumb: a healthy run skips a handful of rows for boring reasons. A run that skips almost everything is not a quiet day upstream, it is a parser that no longer matches its input.

3. Refuse bulk changes that are too large to be real

This one is about the cleanup job, not the import.

Stale inventory is a real problem. Records that vanish from a feed should eventually be deactivated, or you are serving dead links. So most pipelines grow a cleanup job: anything not seen in N days gets switched off.

Now put that job next to the failure above. For eight days, every row from that source was absent from the parse result. A cleanup job doing its work correctly, by its own logic, would have deactivated all 1126 of them. The outage would have gone from invisible to catastrophic, and it would have looked like my data was simply gone.

The fix is a threshold the job refuses to cross:

from feed_guard import guard_bulk_change, BulkChangeRefused

for source, gone in disappeared.items():
    try:
        guard_bulk_change(
            total=totals[source],
            affected=len(gone),
            max_pct=20,
            max_abs=50,
            label=source,
        )
    except BulkChangeRefused as exc:
        log.error("%s", exc)
        continue
    deactivate(gone)

The reasoning behind the numbers: real inventory decays a few rows at a time. Listings close, products sell out, items are withdrawn. It is gradual, and it is uncorrelated across sources. A fifth of one source disappearing overnight is not that pattern. It is a parser symptom, or an upstream outage, and the correct response is to do nothing and say so loudly.

Note that the guard is per source, not global. Twenty percent of your whole dataset is a different event from twenty percent of one feed, and the per-source version catches the case where ten sources are fine and one is broken. That is the case you will actually hit.

Ordering matters as much as thresholds

A cleanup job with perfect thresholds still does the wrong thing if it runs at the wrong moment.

Mine sits between the fetchers and the publisher:

13:20  fetchers start
13:25  last fetcher finishes
13:30  cleanup runs
13:35  page generator runs

Run the cleanup before the fetchers and it acts on yesterday's data. Run it after the publisher and you generate pages for records you are about to retire. The window between "everything that writes has finished" and "anything that reads begins" is the only correct slot, and it is worth writing down explicitly rather than discovering it later.

Putting it together

Three checks, in the order you should add them:

1. Freshness per source. Four lines of SQL. Catches the whole class of silent failures and costs nothing.

2. Skip counters in every parse loop. Turns a silent discard into a number in your log.

3. A circuit breaker before anything destructive. Written before the destructive job, not after it.

The code is in a small repo, no dependencies, one file: feed-guard. Copy the file into your project, or just copy the ideas. The ideas are the point.

One last thing worth saying plainly, because it took me eight days to learn it: exit code 0 means the script finished. Whether it did its job is a separate question, and the only way to answer it is to measure the result rather than the run.

I run Parkzie, a Dutch holiday park comparison site, on my own. Eleven feeds, three languages, one person, which is exactly the setup where a silent failure gets to live for eight days.