August 2026 · Datasource Pulse

How to Monitor an Apify Actor for Failures, Even One You Don’t Own

The answer: watch the actor’s run history and its output, not just its run status. A failed run is the easy case; any monitor catches a red run. The failures that actually cost you are the ones where the run status stays green: successful runs that deliver zero items, output whose field names quietly changed, record counts that collapsed without a single error. Reading run metadata and sampling the latest dataset through the Apify API catches both kinds, it needs only a read-scoped token, and it works on any public actor, including actors you did not build and cannot see the code of.

That last part matters because most Apify pipelines run on rented wheels. The TikTok scraper, the Google Maps scraper, the LinkedIn one: you did not write them, and the maintainer does not know you exist. When a breaking change ships, nothing in your stack crashes. Your pipeline just starts inheriting someone else’s decisions, silently. The usual conclusion is that you cannot monitor what you do not own. This post is the practical version of why that conclusion is wrong.

What a green run status does not tell you

SUCCEEDED is a process statement, not a data statement. It means the container exited cleanly. It does not mean the scraper found anything, that the fields your parser expects still exist, or that the 900 records you got yesterday did not become 9 today. Run-status monitoring catches failed runs and timeouts, which is necessary and not sufficient: the expensive incidents are the silent ones your downstream tables discover days later.

What you can actually see

You cannot put a log line inside code you do not control. But through the Apify API, with an ordinary read-scoped token, you can see everything that matters operationally: the actor’s public release history, the metadata of recent runs, and a sample of the latest output. Datasource Pulse turns those windows into six distinct alarms, each with a stable failure_class your automation can branch on:

• actor_failed The runs stop finishing successfully. The classic failed run. Datasource Pulse tracks the most recent run and the 7-day and 30-day success rates, so one flaky retry does not page you but a real regression does.
• zero_yield Runs keep succeeding and keep delivering nothing. Consecutive successful runs that each produce zero dataset items. The run status is green the whole time; the output is empty. This is the failure that looks like success, and run-status monitoring cannot see it by definition.
• schema_drift The field names in the output changed. A renamed or dropped field is the silent killer: nothing errors, and every downstream join quietly starts returning nulls. The probe samples items from the latest successful run and compares them against a learned baseline.
• volume_drop The record count fell below its rolling baseline. Nine hundred rows yesterday, ninety today, zero error messages. This signal is a per-check toggle, for reasons covered below.
• cost_spike Compute cost per run climbed above its baseline. The failure mode that shows up on your bill instead of in your data. Also a per-check toggle.
• actor_stale The maintainer stopped shipping. If the actor has not been updated in longer than your threshold, you get a heads-up. Not an outage, a forecast: unmaintained scrapers break on the next platform change.

One block of JSON

A watch on someone else’s actor is one entry in the checks array of the Datasource Pulse input. Here is a real one, pointed at a popular TikTok scraper:

{
  "type": "actor",
  "id": "tiktok-scraper-watch",
  "label": "clockworks TikTok Scraper",
  "actorId": "clockworks~tiktok-scraper",
  "apifyToken": "YOUR_APIFY_TOKEN",
  "enableVolumeBaseline": false,
  "enableCostBaseline": false,
  "stalenessThresholdDays": 30
}

The probe is read-only: it looks at the actor record, run metadata, and a dataset sample, and never executes the actor itself. It starts no runs and adds nothing to anyone’s compute bill, so a token scoped to Actor and run read access is all it needs, and a slow multi-phase scraper does not slow the check. A typical healthy check answers in one to three seconds.

The false-alarm footnote

The volume and cost baselines assume the same query runs repeatedly. If you run the actor with different inputs each time, different search terms, different targets, leave both baseline toggles off, exactly as in the block above. The always-on signals, failed runs, zero yield, schema drift, and staleness, still cover you, and you skip the false alarms entirely.

What it costs

Two cents per check, charged per attempt, with no subscription and no start fee. Dependency actors change on release cadence, not by the hour, so once a day is the right frequency. That works out to about $0.61 a month to watch one actor. If the scraper feeds anything a customer sees, that is the cheapest insurance in your stack.

Three ways to switch it on

• A ready-made example task. Monitor Clockworks TikTok Scraper for failures and drift is a one-click task: open it, swap in your token and actor ID, hit Run.
• The n8n route. The actor output drift monitor template on the n8n integration page wraps the same check in a daily schedule and emails you anything unhealthy.
• A plain Apify schedule. Paste the block into the actor’s input on the Datasource Pulse page and attach a daily schedule in the Apify console. No other tooling required.

Where the other monitors end

To be fair to the landscape: Apify’s built-in monitoring is free on every plan and alerts on run status, run metrics, and, if you configure a dataset schema, on output validation too. Community monitors in the Store watch failed runs, empty datasets, and long runs for actors in your own account, and do it well. Both stop at the same two boundaries. They watch actors you own, not the Store dependencies you rent, and they watch the actor alone, not the API keys, quotas, and vendor endpoints around it that fail just as silently. Those two boundaries are exactly where the six alarms above take over. The credential half of that story, dead keys, exhausted quotas, and the four verdict classes that separate them, has its own field guide.