August 6, 2026 · Case study

Two scrapers changed their output on the same week. Triage took one question.

This week our own monitoring flagged schema drift on two Apify Store scrapers we depend on: a Reddit scraper stopped returning post titles and community names, and the Instagram scraper dropped alt text, image dimensions, and tagged users. Both runs exited green. Both datasets parsed fine. Without a fingerprint comparison, nothing anywhere would have looked wrong. Here is the full incident, timestamps and all, and the one question that resolved it in minutes: do we even read those fields?

What the alerts said

We run Datasource Pulse on our own stack daily. The 06:00 UTC run on August 5 came back 38 healthy, 3 failing. One failure was a known rate-limit flap. The other two were new, both filed under the schema_drift failure class at high severity:

A single drifted run can be noise: a bad sample, a partial response, a vendor hiccup. So the first move was no move. The next scheduled run, roughly thirty hours later, reported the identical field lists on both scrapers. Two consecutive runs with the same missing fields upgraded the verdict from possibly transient to confirmed: the vendors changed what they ship.

The triage question nobody starts with

The instinct when a vendor drifts is to open the vendor's changelog, or their issue tracker, or a support ticket. All of that is the slow path, and most of it is someone else's queue. The fast path is one question about your own code: which of the missing fields does our pipeline actually read?

The team consuming these scrapers audited their readers the same day. The result, field by field:

Instagram: the pipeline works entirely from post captions and hashtags. Alt text, image dimensions, tagged users: none of them are read anywhere. Impact of a high-severity drift: zero.

Reddit: post titles are consumed, but they arrive from a separate search-based discovery pass, not from the scraper that drifted. Community names were read from this scraper, but as one of several redundant sources, so the pipeline degrades to still works without a code change.

Total remediation: update the stored schema baselines so the new shape is treated as normal and the alerts go quiet. No code shipped. No customer-facing data affected. The entire incident, from first alert to closed, spanned about a day, and most of that was deliberately waiting for the confirming run.

Severity lives in the consumer, not the vendor

The uncomfortable lesson in this incident is that the vendor cannot tell you how bad a drift is, and neither can the monitor. Both scrapers genuinely lost fields; the monitor was right to call it high severity, because a missing usually-present field is exactly what a breaking change looks like from the outside. Whether it actually breaks anything is decided entirely by which fields your pipeline reads. The same drift that was harmless for this pipeline would have been a production incident for a team rendering Instagram alt text or grouping Reddit posts by community name.

That is why the triage order matters: confirm the drift is real (two consecutive runs), then interrogate your own readers, and only then, if you do read a lost field, go looking for where the data went. When you do, there are three endings. The field was renamed or moved, which is a small reader fix. The field moved behind an input option, common when scraper vendors gate detail levels to cut cost, which is a one-line input change. Or the field is genuinely gone, which is not a code fix at all but a product decision: degrade, re-source, or drop the feature that needed it.

The counterfactual, priced

Without the fingerprint comparison, this incident has a different shape. The fields go hollow silently. Downstream tables accept the empty values, because most schemas do. Nothing pages. Weeks later a report looks thin, someone traces it backward through the pipeline, and the diagnosis that took one question now takes a day of archaeology, starting from the symptom instead of the cause. That delayed version is the normal way teams discover schema drift, and it is the expensive one even when, as here, the drift turns out not to matter.

The vigilance layer that produced the early version of the story costs almost nothing. Our own daily run checks 41 sources, scrapers, keyed APIs, public registries, and the platform quota itself, and bills well under a cent per run as the account owner; at the public Store price the same drift check is $0.02 per scraper per run, about $0.61 a month on a daily schedule. The mechanics of the fingerprint-and-diff pattern, including the sampling traps that make homemade detectors page you at 3 a.m., are in the schema drift field guide; watching a Store actor you did not build, including failed runs and maintainer staleness, has its own guide.

One caveat we are keeping in our own back pocket, and you should too: vendors that silently drop fields tend to keep drifting. The day this Reddit scraper loses comment bodies or the Instagram scraper loses captions is the day the same alert means a real incident for us. The monitor does not know the difference. The triage question does, and it takes minutes when you can start from the exact fields and the exact date they vanished.