Monitor Class I FDA Recalls

A useful monitor remembers what it saw. The FDA Recalls Scraper supplies structured snapshots from the official openFDA food, drug, and device enforcement APIs; your workflow decides what counts as a change.

Define the state

Use product type plus recall number as the stable key; watch status, classification, termination date, firm, reason, and affected product codes. Save the input beside each snapshot so a query change is not mistaken for a source change. Schedule the saved Apify Task at the source's actual update cadence. Hourly polling is wasteful for a feed that changes daily.

On each successful run:

1. Load the previous successful dataset.
2. Join on product_type plus recall_number.
3. Separate new records, changed records, and records that disappeared.
4. Alert only after applying the business filters.
5. Retain the raw snapshot and run ID for investigation.

Do not replace the previous snapshot after a failed or empty run. An upstream outage otherwise looks like mass deletion.

Keep alerts useful

Store the composite key product_type:recall_number. Route ongoing Class I events immediately, send Class II events to the relevant quality owner, and close alerts only after a termination date or documented review.

Alert payloads should include the source identifier, the fields that changed, the old and new values, and a direct source URL. That is enough for an owner to verify the event without opening the raw dataset.

Enforcement records change during an investigation. Refresh ongoing recalls and retain code_info and distribution_pattern. A company-name match alone is not enough to decide whether inventory is affected.

Measure alert precision for the first few weeks. If reviewers repeatedly dismiss the same pattern, tighten the source query or the routing rule. Hiding noise after it enters the alert channel is harder than excluding it at collection time.