Actor Reliability & Drift Monitor

What Is Actor Reliability & Drift Monitor?

Actor Reliability & Drift Monitor continuously monitors Apify Actors and Tasks end-to-end and detects production incidents before they break downstream pipelines.

• Prevent silent failures: catch SUCCEEDED runs that quietly return incomplete or degraded data (volume collapse, pagination stalls, soft blocks).
• Detect schema drift early: field removals, type changes, null spikes, and critical-field breakage that would otherwise crash ETL/CRM ingestion.
• Track reliability regressions: failure-rate spikes and latency (P90) anomalies versus rolling baselines.
• Surface blocking signals: CAPTCHA, rate-limit spikes, and block patterns inferred from run status messages.
• Control alert noise: deterministic event IDs plus cooldowns and multi-run confirmation to avoid spam.
• Prove recovery: explicit incident recovery events and lifecycle tracking for audits and SLA reporting.

The monitor adds an observability layer on top of your existing scrapers without modifying them. It builds robust statistical baselines (median + MAD), freezes learning during incidents, and emits structured events and rollups for dashboards.

What Does Actor Reliability & Drift Monitor Output?

monitorEvents (event stream)

• Rule IDs and severity taxonomy
• Schema drift details (field/type/null)
• Volume metrics (dropFactor, coverage, stall hints)
• Incident ledger lifecycle (open/closed)
• Recovery events (INCIDENT_RECOVERED)
• Alert delivery audit (alertDeadLetters)

runRollups (health snapshots for dashboards)

• Explainability (contributors, weightsUsed, metricBreakdown)
• zScores versus baseline (MAD-derived deviation)
• Baseline stats (median, MAD, histories)
• Rollup integrity checks for dashboards
• Summary reporting support (monitorReports)
• Backed by STATE_SNAPSHOT (baselines, cooldowns, cache)

Core Abilities

• Monitor anything: Actors, Tasks, or explicit Run IDs.
• Baseline by input: perActor / perTask / perInputSignature to prevent baseline mixing across configs.
• Detect more than failures: volume collapse, pagination stalls, schema degradation, and soft blocks.
• Alert safely: deterministic event IDs, cooldown windows, retry plus dead-letter capture.
• Run efficiently: bounded concurrency and sampling budgets to control monitoring cost.
• Integrate anywhere: Slack webhook, generic webhook, and datasets for BI/warehouse ingestion.

Input

The input should include one of: Actor IDs, Task IDs, or explicit Run IDs. You can configure sensitivity, baseline strategy, sampling limits, and alert delivery.

Targets:

• Actors (recommended when you own the scraper and want broad coverage)
• Tasks (recommended for production pipelines with fixed schedules)
• Run IDs (recommended for validation and controlled test cases)

Good setup example:

• Monitor Task IDs for production scrapers plus enable Slack alerts.

Bad setup example:

• Monitor thousands of unrelated Actors at once with aggressive thresholds and no sampling limits.

Baseline mode:

• perActor (lowest cardinality, most general)
• perTask (recommended for production)
• perInputSignature (default; prevents baseline contamination across different input parameter sets)

Signature controls:

• Use include/exclude controls to ignore volatile keys (dates, seeds, offsets) and prevent cardinality explosion.

Threshold profile:

• conservative (fewer alerts, higher confidence)
• balanced (default)
• aggressive (earlier detection, more alerts)

Learning and silence windows:

• Mute alerts during baseline learning (events still recorded)
• Configure silence windows (for example, maintenance hours)

Example input:

{
  "actorIds": ["compass/crawler-google-places"],
  "taskIds": [],
  "runIds": [],
  "monitoringFrequencyMinutes": 15,
  "baselineMode": "perInputSignature",
  "thresholdProfile": "balanced",
  "learningPeriodPolls": 2,
  "schemaCriticalFields": ["id", "url"],
  "schemaSampleEveryNPolls": 2,
  "maxRunsPerPoll": 50,
  "maxConcurrency": 5,
  "maxDatasetSamplesPerPoll": 3,
  "alerts": {
    "slackWebhookUrl": "https://hooks.slack.com/services/XXX/YYY/ZZZ",
    "webhookUrl": "",
    "cooldownMinutes": 60,
    "maxRetries": 5,
    "initialBackoffMs": 500,
    "dedupeBufferSize": 500
  }
}

Output

Results are stored in datasets available in Output/Storage tabs and are suitable for both table views and automation pipelines.

Recommended sources:

• monitorEvents for alerts and incident timelines
• runRollups for dashboards and health-score trends

Example emitted monitor event:

{
  "eventId": "d9a1...",
  "ruleId": "VOL_DROP_CRITICAL",
  "ruleFamily": "VOLUME",
  "severity": "CRITICAL",
  "baselineKey": "task:linkedin_profiles|sig:91c...",
  "runId": "run_8472",
  "details": {
    "baselineMedian": 1000,
    "currentCount": 120,
    "dropFactor": 0.12,
    "coverage": 0.12,
    "paginationStall": true
  },
  "baselineFrozen": true,
  "timestamp": "2026-02-17T11:02:12Z"
}

Example emitted rollup record:

{
  "baselineKey": "task:linkedin_profiles|sig:91c...",
  "healthScore": 42,
  "status": "UNHEALTHY",
  "metricBreakdown": {
    "successRate": 0.99,
    "p90DurationSecs": 9.8,
    "currentCount": 120,
    "blockRate": 0.12
  },
  "baselineStats": {
    "volumeMedian": 1000,
    "volumeMad": 40
  },
  "zScores": {
    "volume": 8.1,
    "latency": 4.2
  },
  "contributors": [
    { "ruleFamily": "VOLUME", "impact": -35, "weight": 0.4 },
    { "ruleFamily": "BLOCK", "impact": -18, "weight": 0.3 }
  ],
  "incidentCount": 2,
  "timestamp": "2026-02-17T11:02:12Z"
}

Output contracts:

• ruleId and ruleFamily are stable and versioned (breaking changes only in major versions).
• monitorEvents is append-only; consumers should dedupe by eventId.
• runRollups is point-in-time; treat as timeseries keyed by (baselineKey, timestamp).

How Much Will Scraping Monitoring Cost You?

Actor Reliability Monitor is priced per actor run analyzed.

Pricing per 1,000 monitored actor runs:

• No discount: $10.00 / 1,000 ($0.01 per run)
• Bronze (Starter): $9.00 / 1,000 ($0.009 per run)
• Silver (Scale): $8.00 / 1,000 ($0.008 per run)
• Gold (Business): $7.00 / 1,000 ($0.007 per run)

Platform usage costs are included.

What this means in practice:

• 1,000 actor runs per month: $7–10 per month
• 5,000 actor runs per month: $35–50 per month
• 20,000 actor runs per month: $140–200 per month

How this compares to scraping costs:

• If your average scraper actor run costs $0.05, monitoring at $0.01 adds approximately +20%.
• If your average scraper actor run costs $0.10, monitoring at $0.01 adds approximately +10%.
• If your average scraper actor run costs $0.20, monitoring at $0.01 adds approximately +5%.

In most production setups, monitoring typically adds 5–15% overhead relative to scraping execution cost.

Why this is economically rational:

• Silent schema breakage
• Multi-day volume degradation
• Block/CAPTCHA waves
• Downstream ETL/CRM failures
• SLA violations

For revenue-critical pipelines, preventing a single unnoticed incident typically offsets months of monitoring cost.

FAQ

How does Actor Reliability & Drift Monitor work?

• It polls recent runs of selected Actors/Tasks (or explicit Run IDs), computes run and dataset signals, compares against rolling baselines (median + MAD), confirms anomalies via streak logic, freezes baselines on breaking incidents, records events, updates incident ledger, and emits recovery when targets return to tolerance.

Will it alert when runs succeed but data is wrong?

• Yes. It detects silent failures like volume collapse, pagination stalls, schema drift, and null spikes even when run status is SUCCEEDED.

Can it integrate with Slack or webhooks?

• Yes. It supports Slack incoming webhooks and generic webhooks with retry, exponential backoff, and dead-letter logging.

Can it run via API?

• Yes. Trigger it via Apify API/SDK and consume monitorEvents and runRollups programmatically.

Is it legal to monitor Actors?

• This actor does not scrape third-party websites itself. It monitors metadata and outputs of runs you choose to monitor. You are responsible for compliance and permissions for monitored Actors and any personal data in their datasets.

Feedback

If you find bugs or want improvements, open an issue in the Actor Issues tab.