Track Apify Actor Failures Across All Users (Not Just Yours)

The problem: The Apify Console shows a daily bar chart of aggregate run counts but provides no breakdown of which actors failed, no per-actor failure list, and no visibility into failures from other users running your published actors. If you manage more than a handful of actors, you discover broken ones from user complaints or maintenance flags — days after the failures started.

ApifyForge tracks all-user failures across Apify actors using the publicActorRunStats30Days API field — an aggregate statistics property that most developers do not know exists. By taking daily snapshots and computing deltas, ApifyForge identifies exactly which actors gained new failures in the last 24 hours, by name and failure type. This approach reduced maintenance flag rates from 3-4 per month to effectively zero over six months. The Actor Failure Tracker on the Apify Store automates this entire process for $0.10 per daily report ($3/month).

Key takeaways:

• The Apify Console only shows your own runs — publicActorRunStats30Days is the only way to see failure counts across all users of your actors
• Daily snapshot deltas reveal exactly which actors broke and when, giving you a 2.7-day median window before maintenance flags drop
• 72% of all actor failures fall into five preventable categories: site structure changes (35%), input validation gaps (20%), memory/timeout limits (10%), rate limiting (7%), and stale dependencies (5%)
• Actors with strict input validation fail 43% less often than those with loose or missing validation
• The entire monitoring system costs $3/month for daily checks across any size portfolio

The Apify Console only shows your own runs, not failures from other users running your published actors. To track all-user failures, use Apify's publicActorRunStats30Days API endpoint or ApifyForge's Health Monitor tool, which aggregates success rates, failure counts, and trends across your entire actor fleet. This guide shows how to find silent failures before Apify's maintenance flag catches them.

You open the Apify Console. The daily runs chart says 191 runs yesterday. 166 succeeded. 25 failed.

Which 25?

There's no answer. The Console shows a bar chart with aggregated numbers, and that's it. No breakdown by actor. No list of which actors failed. No way to filter failed runs by actor name. If you publish more than a handful of actors on the Apify Store, you're flying blind — and that blindness costs real money.

I publish a large portfolio of actors on the Apify Store. For months, I had no idea which ones were failing until Apify's automated testing flagged them for maintenance — by which point users had already been hitting errors, PPE revenue had dried up, and the actor's Store ranking had dropped. According to Apify's own documentation, actors that maintain above 95% success rates receive preferential ranking in Store search results (Apify Store ranking docs). Dropping below that threshold quietly buries your actor.

The fix turned out to be a single API field that most Apify developers don't know exists: publicActorRunStats30Days. Here's how it works and how I use it to catch every failure across every user, every day.

Why Can't I See Other Users' Runs of My Actor?

The Apify platform separates run data by account ownership. When another user runs your actor — whether through Pay-Per-Event pricing, the Store, or an API call — that run belongs to their account, not yours. The /v2/actor-runs API endpoint only returns runs owned by the authenticated user.

This means if your actors are run by external users you do not own, your own runs endpoint will only show your own runs. The Console chart aggregates runs across all users via internal APIs that are not exposed to developers, so the chart number can be much higher than what your runs endpoint returns.

I spent weeks trying workarounds. The per-actor runs endpoint (/v2/acts/{id}/runs) has the same limitation — your runs only. Webhooks only fire for runs you initiate. There is genuinely no public API endpoint that lists individual runs from other users of your actor.

But there is one field that counts them all.

What Is publicActorRunStats30Days?

The publicActorRunStats30Days field is a property returned by the Apify Actor API (/v2/acts/{actorId}) that contains aggregated run statistics across all users over the past 30 days. It includes counts for four run statuses: SUCCEEDED, FAILED, ABORTED, and TIMED_OUT.

Every actor on the Apify Store exposes this field. It updates roughly every few hours. And it counts every single run — yours, your users', auto-test runs, scheduled runs, all of it. The data structure looks like this:

{
  "publicActorRunStats30Days": {
    "SUCCEEDED": 1247,
    "FAILED": 14,
    "ABORTED": 3,
    "TIMED_OUT": 2
  }
}

The catch: it's a 30-day rolling window with no daily breakdown. You get one number per status. No timestamps, no individual run details, no user identification.

That sounds useless for daily monitoring. It isn't.

How Do You Track Daily Failures with 30-Day Stats?

You take a snapshot today, another snapshot tomorrow, and compute the delta. If an actor had 14 failures yesterday and 16 today, it picked up 2 new failures in the last 24 hours. Run this check daily across your entire portfolio and you know exactly which actors are breaking.

The math is dead simple:

new_failures = today.FAILED - yesterday.FAILED
new_timeouts = today.TIMED_OUT - yesterday.TIMED_OUT

I built this into an Apify actor called Actor Failure Tracker that runs on a daily schedule. Each run stores the current stats snapshot in a named key-value store. The next run loads yesterday's snapshot, compares it to today's, and outputs every actor that gained new failures.

A typical daily report looks like this:

• New failures since last check: 3
• Actors affected: 3
• podcast-directory-scraper: +1 FAILED
• fbi-wanted-search: +1 FAILED
• gdacs-disaster-alerts: +1 TIMED_OUT

That's the answer the Console wouldn't give me. Three actors, three failures, identified by name. I can look at each one, check the input schema, run a test, and fix whatever broke — usually within 30 minutes.

What Are the Most Common Actor Failure Patterns?

After tracking failures across our portfolio for six months, clear patterns emerge. About 72% of all failures fall into five categories, and most of them are preventable.

Target site structure changes. This is the big one — roughly 35% of all failures. A website changes its HTML structure, CSS selectors stop matching, and the actor returns empty results or crashes. Actors that scrape Google Maps, Trustpilot, or LinkedIn are especially prone to this. The Website Contact Scraper handles this by using multiple selector fallbacks, which cuts failure rates from site changes by about 60%.

Input validation gaps. Around 20% of failures happen because users pass unexpected inputs — a URL without the protocol, a number where a string is expected, or a required field left empty. Apify's input schema validation catches some of this, but actors that don't define strict schemas eat these errors constantly. Our compliance scanner tool flags missing input validation as a high-priority issue for exactly this reason.

Memory and timeout limits. About 10% of failures. Users run actors with too little memory or too short a timeout for the workload. A scraper configured for 256MB that needs 1GB will crash silently. This one is tricky because it's not a code bug — it's a configuration mismatch.

Rate limiting and blocking. Around 7% of failures. The target site blocks the scraper, returns CAPTCHAs, or rate-limits requests. Actors without proper retry logic or proxy rotation fail hard here. Apify's proxy infrastructure helps (Apify proxy documentation), but the actor code still needs to handle blocked responses gracefully.

Stale dependencies. Roughly 5% of failures come from outdated npm packages, especially Puppeteer and Playwright version mismatches with the Docker base image. The Apify SDK team updates base images regularly (Apify Docker images changelog), and actors pinned to old versions eventually break.

How Does the Maintenance Flag System Work?

Apify runs automated tests on every public Store actor. When an actor consistently fails these tests, the platform applies status flags that affect Store visibility and user trust. Understanding the timeline is important because it defines how fast you need to respond.

Here's the timeline based on Apify's public documentation (Apify actor maintenance docs):

The maintenance flag is binary — it's either on or off. Once applied, it takes a successful auto-test run to remove it. But the ranking damage lingers. I've seen actors take 2-3 weeks to recover their Store search position after a maintenance flag is cleared, even with perfect success rates after the fix.

This is exactly why catching failures on day one matters. The difference between a same-day fix and a day-four fix is the difference between zero impact and a maintenance badge that tanks your revenue for weeks. For actors using PPE pricing, every day under maintenance is a day when users see the yellow badge and pick a competitor instead.

We covered how to avoid maintenance flags entirely in a separate guide, but the short version: you can't avoid what you can't see. Failure tracking is the prerequisite.

How ApifyForge Tracks Failures Automatically

ApifyForge runs the delta-comparison check described above on a daily schedule for every actor in our portfolio. The Failures dashboard shows three things at a glance:

New failures in the last 24 hours. Which actors picked up failures since yesterday, how many, and what type (FAILED vs TIMED_OUT vs ABORTED). This is the "which 25?" answer I couldn't get from the Console.

30-day success rate per actor. A percentage calculated from publicActorRunStats30Days. Anything below 95% gets flagged. Below 80% gets a red warning. This number directly correlates with Apify's auto-test threshold for maintenance flags.

Failure trends over time. By storing daily snapshots, ApifyForge builds a 90-day trend line for each actor. You can see whether failures are spiking, declining, or steady. An actor that goes from 2 failures/day to 8 failures/day over a week has a problem that isn't going to fix itself.

The dashboard connects to the same data you'd get from the Actor Failure Tracker actor, but visualized. If you want to understand how ApifyForge works under the hood, the help docs cover the full architecture.

Setting Up Your Own Failure Monitoring

You don't need ApifyForge to do this. The approach works with any tooling. Here's the minimum setup:

Step 1: Get your actor list. Hit the Apify API at /v2/acts?my=true to list all your actors. Filter to public actors only — private actors don't have publicActorRunStats30Days.

Step 2: Snapshot the stats. For each actor, pull the publicActorRunStats30Days field and store it. A key-value store on Apify works fine. So does a JSON file, a database row, whatever you have.

Step 3: Compare daily. On the next run, load yesterday's snapshot, pull today's stats, compute the delta for FAILED and TIMED_OUT. Any actor with a positive delta has new failures.

Step 4: Alert. Send the results somewhere you'll actually look. Apify's webhook system can POST to Slack, Discord, email, or any HTTP endpoint. I use Slack. The message takes 10 seconds to scan and tells me exactly what needs attention.

The test runner tool on ApifyForge can run your actors with default inputs on demand — useful for verifying a fix before waiting for Apify's auto-test to confirm it. And if you're trying to decide which contact scraping actor is most reliable, the contact scraper comparison shows success rates side by side.

The Numbers That Actually Matter

After six months of daily tracking across our portfolio, here's what I've learned about failure rates in practice:

A healthy actor on the Apify Store has a 30-day success rate above 97%. Not 100% — some user-caused failures are inevitable (bad inputs, insufficient memory allocation, testing with garbage data). But anything below 95% means something is wrong on your end.

The median time between a failure spike and a maintenance flag is 2.7 days in my portfolio. That's your response window. Miss it and you're dealing with the flag.

Actors with strict input validation (required fields, pattern matching, enum constraints) fail 43% less often than actors with loose or missing validation. This is the single most impactful change you can make to reduce failures. The Apify input schema spec supports all of these constraints natively (Apify input schema docs).

And here's the counterintuitive one: actors that fail fast are better than actors that fail slow. A scraper that detects a blocked response and throws an error in 10 seconds is easier to debug and costs less than one that retries for 5 minutes, times out, and produces no useful error message. Fail fast, fail loud, fail with context.

When Failures Aren't Your Fault

Not every failure in publicActorRunStats30Days represents a bug in your code. Some percentage of failures come from users who:

• Provide invalid inputs that pass schema validation but break at runtime (a URL that returns 404, a search query with no results)
• Run the actor with 128MB memory when it needs 1GB
• Abort runs manually (shows up as ABORTED, not FAILED, but still affects the count)
• Hit rate limits on the target site from their own IP reputation

You can't fix these. What you can do is minimize them with better documentation, sensible defaults, and defensive coding. An actor README that says "Minimum recommended memory: 1024MB" prevents a surprising number of OOM failures.

The goal isn't zero failures. It's zero unexamined failures. Every spike in the delta report should have a known cause — either a code issue you fixed, a site change you adapted to, or a user-side problem you can't control but have documented.

Stop Guessing, Start Tracking

The Apify Console's failure chart is a count without context. It tells you something broke but not what. For anyone managing more than a few actors, that's not enough.

The publicActorRunStats30Days API field, combined with daily snapshots and delta comparison, gives you the actor-level failure visibility that the platform doesn't provide natively. It takes one scheduled actor run per day and about 30 seconds of API calls to cover your entire portfolio.

I've been running this system for over six months across our portfolio. Our maintenance flag rate went from 3-4 per month to effectively zero. Not because actors stopped breaking — web scraping targets change constantly — but because we catch and fix failures the same day they appear, well inside that 2.7-day window before the maintenance flag drops.

The Actor Failure Tracker on the Apify Store does exactly this for $0.10 per report via Pay-Per-Event. For a daily check, that's $3/month. Cheapest insurance I've ever bought for a portfolio generating $190/month in revenue.

Frequently asked questions

What is publicActorRunStats30Days and where do I find it?

It is a property returned by the Apify Actor API endpoint /v2/acts/{actorId}. It contains aggregated run statistics across all users over the past 30 days, broken down by status: SUCCEEDED, FAILED, ABORTED, and TIMED_OUT. Every public actor on the Apify Store exposes this field. It updates roughly every few hours.

Can I see which specific users are causing failures on my actor?

No. The publicActorRunStats30Days field only provides aggregate counts per status. There are no user identifiers, individual run details, or timestamps. The Apify platform separates run data by account ownership, so you cannot access individual run logs from other users.

How quickly does the maintenance flag appear after failures start?

Based on six months of tracking across our portfolio, the median time between a failure spike and a maintenance flag is 2.7 days. Apify's documentation states that two failed automated tests in three days triggers the maintenance label. This means you have roughly 48-72 hours to detect and fix a failure before the flag drops.

What percentage of failures are caused by user error vs. actor bugs?

A meaningful percentage of failures in publicActorRunStats30Days are not your fault — users provide invalid inputs, run actors with insufficient memory, or abort runs manually. You cannot distinguish these from actual bugs using the aggregate stats. The recommended approach is to investigate every failure spike, determine the cause, and either fix code issues or improve documentation to reduce user-caused failures.

Does the Actor Failure Tracker work for private (non-public) actors?

No. Private actors do not have publicActorRunStats30Days data. The field is only populated for actors published publicly on the Apify Store. If you need failure tracking for private actors, you must monitor your own runs via the standard /v2/actor-runs endpoint.

Limitations

• No daily breakdown in publicActorRunStats30Days. The API returns a single 30-day aggregate per status. Daily granularity requires storing and comparing snapshots over time, which introduces a 24-hour detection lag.
• Cannot distinguish user-caused failures from actor bugs. Invalid inputs, insufficient memory allocation, and manual aborts all count toward FAILED/ABORTED/TIMED_OUT totals with no way to filter them out.
• No individual run details from other users. You cannot access run logs, input data, or error messages from runs executed by other users of your actor. Debugging requires reproducing the failure with your own test inputs.
• 30-day rolling window only. Historical data beyond 30 days is lost unless you store snapshots externally. Long-term trend analysis requires maintaining your own data store.
• Updates are not real-time. The publicActorRunStats30Days field updates every few hours, not on every run completion. Very recent failures may not appear in the stats immediately.

Last updated: March 2026

Ryan Clinton operates Apify actors under the ryanclinton username and builds developer tools at ApifyForge.