How Devil Scrapes Maintains and Supports Actors

A scraper that worked last month can break this month for reasons that have nothing to do with our code — a target redesigns a page, moves an API, or tightens its defenses. Maintaining 202 live Actors means treating that as the normal state of things, not an exception. This page is a straight account of how we watch the fleet, how we prioritize fixes, and how to get a problem in front of us.

Daily monitoring across the fleet

Every Actor is checked daily against its own recent run history — not spot-checked occasionally, all 202. We track success rate over a rolling 30-day window per Actor: across the fleet, the last 30 days show 16,077 customer runs at a 96.1% success rate. That number is a fleet average, not a promise about any single Actor on any single day — an individual Actor can dip below that if its target changes something, which is exactly what the daily check exists to catch quickly rather than let sit for weeks.

Triage priorities

When a break shows up, we work through it in roughly this order:

1. Actors currently returning wrong or zero data for a target that used to work — a silent regression is worse than a loud one, because customers building on it don’t know to stop trusting the output.
2. Actors failing outright (FAILED runs) rather than degrading quietly — visible failures are already surfacing themselves; the priority is turning them around fast, not that they’re more severe in isolation.
3. Partial-success drift — an Actor that used to return full result sets and now consistently truncates, which the status-message convention in How we handle proxies and blocking is designed to surface early.
4. Everything else — README accuracy, input-schema polish, non-blocking edge cases.

Higher-traffic Actors get attention faster in practice, simply because breaks on them affect more customers and surface in the monitoring signal sooner — not because of a formal tiering.

How to report a problem

Two channels, both real, both checked:

1. The Issues tab on the Actor’s Apify Store listing. This is the most direct route if you’re already looking at the Actor — describe what input you ran, what you expected, and what you got (paste the run ID if you have it; it lets us pull the exact log).
2. Our contact form at /contact/. Use this for anything broader than a single Actor — a question that spans multiple scrapers, a custom-build inquiry, or if you’d rather not use the Apify Issues tab.

The single most useful thing you can include in either channel: the run ID. It lets us pull the exact log and status message for that run instead of guessing at what happened from a description alone.

What “fixed” means here

A fix isn’t “fixed” until it’s been verified against the live platform, not just tested locally. Local test runs don’t exercise Apify’s actual proxy resolution, the built Docker image, or Pay-Per-Event charging — a fix that only passes locally can still fail the moment it’s pushed. Every fix we ship goes through a cloud verification pass against the real target before we consider the issue closed. If you reported a break, we’re not marking it done until a fresh run against the actual site comes back clean.

Response expectations, honestly

We don’t publish a formal SLA, and we’re not going to invent one here just to look reassuring. What’s true: the fleet is monitored daily, and problems that show up in that monitoring get triaged the same day they’re caught. A report that comes in through the Issues tab or the contact form gets read and looked into — how fast depends on the specific Actor, the complexity of what broke, and what else is in the queue at that moment. If you need a guaranteed response window for a business-critical use case, say so in your report; we’ll tell you honestly whether that’s realistic for that specific case rather than promise a number we can’t back.

Refunds

Refunds for a run that charged you but genuinely failed to deliver go through Apify’s own support, since Apify — not us directly — processes the billing and payout on every Pay-Per-Event charge. Apify’s support can see the exact run and charge in question and issue a refund when a run’s outcome doesn’t match what it billed for. If you’re not sure whether a specific charge was a real failure or a legitimate zero-result outcome (see How we handle proxies and blocking for the distinction), reporting it to us first through either channel above is the faster path — we can tell you which it was before you go through Apify support.

FAQ

How often is each Actor actually checked?

Daily, across the entire fleet — every Actor’s recent run success rate gets reviewed as part of a standing monitoring pass, not on an ad hoc or customer-report-triggered basis only.

What’s the fastest way to get a bug looked at?

Report it through the Apify Issues tab on that Actor’s Store listing with the run ID included, or use /contact/ for anything that spans more than one Actor. The run ID is what lets us skip straight to the actual log instead of asking follow-up questions first.

Do you offer a guaranteed response time?

No, and we won’t invent one. We monitor daily and triage same-day when our own monitoring catches something; a customer-reported issue’s response time depends on complexity and queue. If a guaranteed window matters for your use case, tell us — we’ll be straight about whether that’s realistic.

How do I get a refund for a run that failed?

Through Apify’s own support, since Apify processes the billing on every Pay-Per-Event charge. If you’re unsure whether your run was a genuine failure versus a legitimate zero-result success, ask us first through the Issues tab or /contact/ — we can clarify quickly before you go through Apify support.

What counts as “fixed” when you close an issue?

A fix verified with a real run against the live Apify platform and the actual target — not just a local test. We don’t close an issue on a code change alone.