Deprecation Monitor

Actor Deprecation Monitor scans the Apify actors your pipelines depend on for early warning signs of abandonment, deprecation, and declining reliability — before they break your production workflows overnight. Built for data engineers, DevOps teams, and agency developers who depend on third-party actors they do not control.

Feed it a list of actor IDs or username/name slugs and it runs 7 deprecation signal checks per actor, scores each one from 0 to 100, and classifies it as HEALTHY, WATCH, WARNING, or CRITICAL. When any actor crosses your alert threshold, it fires a webhook to Slack, Discord, Teams, or any HTTP endpoint automatically.

What data can you extract?

Why use Actor Deprecation Monitor?

Third-party actors on the Apify Store are maintained by independent developers. Any of them can go silent, raise their prices to discourage use, or simply stop releasing builds. When that happens, your pipelines start failing — usually on a Friday night when nobody is watching.

Manual checks mean opening the Store page for each actor, hunting for the last build date, scanning the run logs for success rate drops, and checking whether the developer is still active. For a portfolio of 10-50 actor dependencies, that is several hours of tedious work per week. With no guarantee you will catch the warning signs in time.

Actor Deprecation Monitor automates the entire process. It queries the Apify API for build history, run statistics, maintenance flags, pricing data, and developer activity, then computes a single risk score you can act on.

• Scheduling — run daily or weekly on the Apify Scheduler to catch problems before pipelines break
• API access — trigger checks from Python, JavaScript, or any HTTP client as part of a CI/CD pipeline
• Webhook alerts — push risk notifications to Slack, Discord, Teams, Zapier, or any HTTP endpoint
• Spending limit controls — set a max budget per run so large actor lists never cause unexpected charges
• Integrations — pipe results into Google Sheets, HubSpot, or a monitoring dashboard via Make or Zapier

Features

• 7 deprecation signals per actor — checks build staleness, version update recency, success rate trend, maintenance flag, explicit deprecation marker, pricing anomalies, and developer activity
• Composite risk scoring 0-100 — signals carry weighted scores (explicit deprecation: 40 points, maintenance flag: 30 points, critically low success rate: 30 points) that sum to a final risk score capped at 100
• Four risk levels — HEALTHY (0-24), WATCH (25-49), WARNING (50-74), CRITICAL (75-100) give you a clear action framework
• Success rate trend analysis — splits the last 100 runs into two halves and flags actors where recent success rate dropped more than 5 percentage points versus older runs
• Build staleness detection — three tiers: 30+ days (10 points), 90+ days (18 points), 180+ days (25 points)
• Version staleness detection — two tiers: 60+ days (10 points), 180+ days (20 points), using the actor's modifiedAt timestamp from the API
• Sunset pricing detection — flags PAY_PER_EVENT actors charging over $1.00 per event as a possible "go away" signal (weight: 15 points)
• Developer activity check — queries all public actors by the same developer and flags those with no modifications in the last 30 days
• Automatic alternative suggestions — when risk score reaches 25 or above, searches the Apify Store using the actor's name keywords and returns up to 3 candidate replacements
• Signal-aware recommendations — generates plain-English recommendations tailored to the dominant signal type (maintenance, stale builds, declining success rate, or pricing change)
• Webhook delivery — POSTs a structured JSON payload to your endpoint when any actor exceeds the alert threshold, including top signal and recommendations
• Per-actor error handling — if one actor fails to load (wrong ID, access restriction), the run continues and flags that actor with an explanatory error rather than aborting the entire batch
• Pay-per-event billing — charged at $0.05 per actor monitored; stops cleanly when your spending limit is reached

Use cases for Apify actor deprecation monitoring

DevOps and pipeline reliability engineering

DevOps engineers who run Apify actors in production ETL pipelines need to know about degradation before it causes an incident. Schedule Actor Deprecation Monitor to run nightly on the same list of actor IDs your pipelines depend on. Connect the webhook to PagerDuty or Slack so on-call engineers get notified while there is still time to switch to a backup before the next scheduled run.

Data engineering and ETL dependency management

Data engineers building long-running pipelines on third-party scrapers cannot afford surprise failures. Running this monitor weekly across your actor dependency list surfaces build staleness and success rate declines weeks before they reach the point of failure. The alternatives field gives you a shortlist of replacement candidates to evaluate without manual Store browsing.

Agency client pipeline management

Agencies maintaining Apify pipelines for multiple clients often depend on a diverse portfolio of community actors. Actor Deprecation Monitor lets account managers run a single weekly check across all client-critical actors and surface risks in a structured report. Proactively migrating a client pipeline before it breaks is far cheaper than a late-night emergency fix.

Apify power user portfolio monitoring

Power users running 10-50 actors across different projects accumulate invisible technical debt as community actors age. A monthly risk scan with this monitor helps you identify which actors in your stack are quietly drifting toward abandonment so you can prioritize replacements before they become urgent.

Developer due diligence before adoption

Before building a new pipeline around an actor you found in the Store, run it through Actor Deprecation Monitor first. A WATCH or WARNING score on a brand-new dependency is a signal to look for a more actively maintained alternative before you invest time building the integration.

Competitive and ecosystem intelligence

Apify developers who publish their own actors can use this monitor to track competitor actors in the same category. When a competing actor enters WARNING status, it is an opportunity to capture migrating users by ensuring your own equivalent actor is up to date and well-documented.

How to monitor actors for deprecation signals

1. Gather your actor IDs — paste the username/actor-name slugs of every actor your pipelines depend on (e.g., apify/web-scraper, bramborman/quickscraper). You can find these in the Store URL for each actor.
2. Enter your API token — paste your Apify API token from console.apify.com/account/integrations. This is needed to query build history and run statistics.
3. Set an alert threshold — leave it at the default of 60 to be notified about WARNING and CRITICAL actors. Lower it to 25 if you want early alerts on WATCH-level actors too.
4. Add a webhook URL (optional) — paste your Slack incoming webhook URL or any other HTTP endpoint to receive alerts automatically when actors cross the threshold.
5. Click Start — a typical run across 10-20 actors completes in 2-5 minutes. Download the full risk report from the Dataset tab as JSON, CSV, or Excel.

For continuous protection, schedule this actor to run daily via the Apify Scheduler using the same input. Connect the webhook to your team's Slack channel and you will never be surprised by a silent actor failure again.

Input parameters

Input examples

Daily pipeline health check (recommended):

{
  "apiToken": "apify_api_YOUR_TOKEN_HERE",
  "actorIds": [
    "apify/web-scraper",
    "apify/cheerio-scraper",
    "bramborman/quickscraper",
    "drobnikj/extended-gpt-scraper"
  ],
  "alertThreshold": 60,
  "webhookUrl": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX"
}

Large portfolio scan with early-warning threshold:

{
  "apiToken": "apify_api_YOUR_TOKEN_HERE",
  "actorIds": [
    "apify/web-scraper",
    "apify/playwright-scraper",
    "apify/puppeteer-scraper",
    "compass/crawler-google-places",
    "vaclavrut/amazon-crawler",
    "junglee/free-amazon-product-scraper",
    "tri_angle/airbnb-scraper",
    "drobnikj/extended-gpt-scraper"
  ],
  "alertThreshold": 25,
  "webhookUrl": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX"
}

Minimal check — no webhook, just the report:

{
  "apiToken": "apify_api_YOUR_TOKEN_HERE",
  "actorIds": ["apify/web-scraper", "apify/cheerio-scraper"],
  "alertThreshold": 60
}

Input tips

• Start with the default threshold of 60 — this catches WARNING and CRITICAL actors without generating noise from minor WATCH-level signals. Lower to 25 once you are comfortable with alert volume.
• Use username/actor-name slugs, not actor page URLs — the slug is the last two path segments of the Store URL (e.g., apify/web-scraper from apify.com/apify/web-scraper).
• Batch all dependencies in one run — processing 20 actors in a single run costs $1.00 and takes about 3 minutes. Running them individually adds unnecessary overhead.
• Schedule daily for production pipelines — actors can go from HEALTHY to CRITICAL in a matter of days if a developer deletes their account or sets a maintenance flag. Daily runs give you the earliest possible warning.
• Connect the webhook to a dedicated Slack channel — a #apify-alerts channel keeps deprecation warnings out of general noise and makes them easy to triage.

Output example

Individual actor report (one per actor monitored):

{
  "actorName": "web-scraper",
  "actorId": "YPh5JENjSSZmhMyZl",
  "developer": "legit-dev",
  "riskScore": 68,
  "riskLevel": "WARNING",
  "signals": [
    {
      "signal": "Last build 145 days ago (3+ months stale)",
      "weight": 18
    },
    {
      "signal": "Success rate dropped from 91% to 68%",
      "weight": 25
    },
    {
      "signal": "Last version update 210 days ago (6+ months)",
      "weight": 20
    }
  ],
  "recommendation": "Success rate is declining, which often precedes full deprecation. Start evaluating alternatives and prepare a migration plan.",
  "alternatives": [
    "apify/web-scraper-v2",
    "ryanclinton/website-contact-scraper",
    "bramborman/quickscraper"
  ],
  "checkedAt": "2026-03-20T09:15:00.000Z"
}

Summary row (always the last record in the dataset):

{
  "type": "summary",
  "totalMonitored": 8,
  "healthy": 4,
  "watch": 2,
  "warning": 1,
  "critical": 1,
  "highestRisk": "web-scraper",
  "highestRiskScore": 68,
  "alertSent": true,
  "checkedAt": "2026-03-20T09:17:43.000Z"
}

Output fields

Deprecation signals and scoring

The actor checks 7 categories of signals. Scores accumulate and are capped at 100.

How much does it cost to monitor actors for deprecation?

Actor Deprecation Monitor uses pay-per-event pricing — you pay $0.05 per actor monitored. Compute time is included in the price.

You can set a maximum spending limit per run to control costs. The actor stops cleanly when your budget is reached — remaining actors are not processed, but all completed checks are saved to the dataset.

Apify's free tier includes $5 of monthly credits — enough to monitor 100 actors per month at no cost. Comparable paid monitoring tools for SaaS API dependencies charge $50-150/month. Most users of this actor spend $1-5/month.

Monitor actors for deprecation using the API

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

run = client.actor("ryanclinton/actor-deprecation-monitor").call(run_input={
    "apiToken": "YOUR_API_TOKEN",
    "actorIds": [
        "apify/web-scraper",
        "apify/cheerio-scraper",
        "compass/crawler-google-places"
    ],
    "alertThreshold": 60,
})

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item.get("type") == "summary":
        print(f"Summary: {item['healthy']} healthy, {item['warning']} warning, {item['critical']} critical")
    else:
        print(f"[{item['riskLevel']}] {item['actorName']} — score {item['riskScore']}: {item['recommendation']}")

JavaScript

import { ApifyClient } from "apify-client";

const client = new ApifyClient({ token: "YOUR_API_TOKEN" });

const run = await client.actor("ryanclinton/actor-deprecation-monitor").call({
    apiToken: "YOUR_API_TOKEN",
    actorIds: [
        "apify/web-scraper",
        "apify/cheerio-scraper",
        "compass/crawler-google-places",
    ],
    alertThreshold: 60,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const item of items) {
    if (item.type === "summary") {
        console.log(`Summary: ${item.healthy} healthy, ${item.warning} warning, ${item.critical} critical`);
    } else {
        console.log(`[${item.riskLevel}] ${item.actorName} — score ${item.riskScore}`);
        if (item.riskScore >= 50) {
            console.log(`  Alternatives: ${item.alternatives.join(", ")}`);
        }
    }
}

cURL

# Start the actor run
curl -X POST "https://api.apify.com/v2/acts/ryanclinton~actor-deprecation-monitor/runs?token=YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "apiToken": "YOUR_API_TOKEN",
    "actorIds": ["apify/web-scraper", "apify/cheerio-scraper"],
    "alertThreshold": 60
  }'

# Fetch results once complete (replace DATASET_ID from the run response)
curl "https://api.apify.com/v2/datasets/DATASET_ID/items?token=YOUR_API_TOKEN&format=json"

How Actor Deprecation Monitor works

Phase 1 — Actor metadata retrieval

For each actor ID or username/name slug in your input list, the actor calls GET /v2/acts/{identifier} on the Apify API. The identifier is normalized to the username~name format the API expects. The response provides the actor's ID, developer username, modifiedAt timestamp, isDeprecated flag, maintenance status from stats.isUnderMaintenance, and the full pricingInfos array. Each API call has a 30-second timeout.

Phase 2 — Signal evaluation

Seven parallel signal checks run against the retrieved metadata and supplemental API calls:

Build staleness — GET /v2/acts/{id}/builds?limit=5&desc=true retrieves the 5 most recent builds. The timestamp of the latest build's finishedAt field is compared against the current date to produce a staleness score in three tiers (30+, 90+, 180+ days).

Version staleness — the actor's modifiedAt field from the base metadata call is used to calculate days since the last code change, scored in two tiers (60+, 180+ days).

Success rate trend — GET /v2/acts/{id}/runs?limit=100&desc=true retrieves the 100 most recent runs. These are split at the midpoint: the first half (newest runs) is compared against the second half (older runs) by counting SUCCEEDED statuses in each half. A drop of more than 5 percentage points is flagged as declining; a drop of more than 20 points triggers the higher-weight "sharp decline" signal.

Pricing anomaly — the pricingInfos array is scanned for PAY_PER_EVENT models where any eventPriceUsd exceeds $1.00. Prices at that level typically indicate a developer discouraging usage rather than seeking revenue.

Developer activity — GET /v2/store?username={developer}&limit=20 retrieves the developer's other public actors. If none of them have been modified in the last 30 days, the developer is flagged as inactive.

Phase 3 — Scoring and recommendation

Signal weights are summed and capped at 100 to produce the final risk score. The score is mapped to a risk level using fixed thresholds: HEALTHY (<25), WATCH (25-49), WARNING (50-74), CRITICAL (75+). A recommendation string is generated by inspecting which signal types dominated the score — maintenance flags, stale builds, declining success rates, and pricing changes each produce distinct recommendation text.

Phase 4 — Alternatives and output

When a risk score reaches 25 or above, the actor extracts keywords from the actor name (filtering words shorter than 4 characters), queries GET /v2/store?search={keywords} and returns up to 3 results that are not the actor itself. The completed report, including all signal details and alternatives, is pushed to the dataset. After all actors are processed, a summary row is pushed. If any actors exceeded the alert threshold and a webhook URL was provided, the structured alert payload is POSTed as the final step.

Tips for best results

1. Run daily for production pipeline actors, weekly for lower-priority dependencies. Build staleness and success rate decline signals appear days before a complete failure. Daily runs give you the maximum lead time to migrate.

2. Treat any CRITICAL actor as an immediate action item. A score of 75 or above means multiple strong signals are present simultaneously. The probability of the actor breaking within 30 days is high.

3. Combine with Actor Health Monitor for full coverage. This actor watches actors you do not control; Actor Health Monitor watches your own actors' runtime performance. Together they cover both sides of pipeline reliability.

4. Lower your threshold to 25 for client-critical pipelines. The default threshold of 60 catches WARNING and CRITICAL actors. A WATCH score of 25-49 is often weeks ahead of WARNING — catching it early gives you more time to plan a migration without urgency.

5. Export results to Google Sheets via the Apify integration. A persistent spreadsheet lets you track risk scores over time and spot actors that are slowly drifting upward week by week. A score that moves from 15 to 30 to 45 over three weeks is a trend worth acting on even before it hits WARNING.

6. Check the alternatives field before panicking. The actor automatically searches the Store for replacement candidates when risk reaches 25. Review the alternatives and test one against your actual pipeline input before the at-risk actor breaks.

7. Do not monitor apify/* actors with lower thresholds. Official Apify-published actors are maintained by the platform team and typically receive long advance notice before deprecation. Community actor developers may disappear without warning.

8. Use the API to integrate deprecation data into your CI/CD pipeline. Run Actor Deprecation Monitor as a pre-deployment check in GitHub Actions — fail the build if any dependency actor reaches WARNING or CRITICAL, forcing the team to address it before shipping.

Combine with other Apify actors

Limitations

• Only queries publicly accessible actor metadata. Private actors are only checkable if your API token has explicit access. The actor cannot check metadata that is hidden from the token you provide.
• Alternatives search is keyword-based, not semantic. The Store search uses actor name keywords. Results may include loosely related actors. Always test an alternative manually before committing to a migration.
• Developer inactivity is a weak signal in isolation. Many developers maintain one well-built actor without touching it for months because it does not need changes. Weight this signal in context of other signals, not on its own.
• Pricing anomaly detection uses a fixed $1.00 threshold. Some legitimate actors price above $1.00 per event for complex processing jobs. A price flag is a reason to investigate, not a definitive deprecation indicator.
• Run success rate data depends on your token's access. If the actor has restricted run data visibility, the trend analysis will fall back to Insufficient run data with no success rate signals.
• No historical trend storage. Each run produces a snapshot. The actor does not compare scores across runs. Use the Google Sheets integration or schedule recurring exports to build a historical trend yourself.
• isDeprecated flag is developer-set. The highest-weight signal (40 points) relies on the developer explicitly marking their actor as deprecated. Developers who quietly abandon actors without setting the flag will not trigger this signal — the other signals exist precisely to catch that case.
• No JavaScript crawling of Store pages. The actor uses the official Apify REST API only. It does not scrape actor pages and cannot detect informal deprecation signals like a developer posting "I'm discontinuing this" in the comments section.

Integrations

• Zapier — trigger a Zap when the webhook fires, creating tickets in Jira, Trello, or Asana for CRITICAL actors
• Make — build a scenario that runs this actor on a schedule and writes results to a Google Sheet for trend tracking
• Google Sheets — append each run's dataset to a master risk log for week-over-week score tracking
• Apify API — trigger runs from GitHub Actions as a pre-deployment dependency check in CI/CD pipelines
• Webhooks — connect the built-in webhook output to PagerDuty, OpsGenie, or any incident management platform
• LangChain / LlamaIndex — feed deprecation risk data into an AI agent that summarizes pipeline risks across your portfolio and drafts migration recommendations

Troubleshooting

Actor returns a score of -1 with an error signal. An actor ID that cannot be resolved returns an error report rather than failing the entire run. The most common cause is an incorrect slug format — use username/actor-name (forward slash), not username~actor-name (tilde). Verify the slug by opening the actor's Store page and checking the URL.

All actors show score 0 or HEALTHY despite suspected issues. The most likely cause is that the actor list contains apify/* official actors, which are actively maintained and rarely trigger staleness signals. If you are checking community actors and getting unexpectedly low scores, verify that your API token has access to the actor's run statistics, as restricted tokens may cause the run data check to fall back silently to 0.

Webhook was not delivered. The webhook delivery requires a public HTTPS URL that accepts POST requests with a JSON body. Local development endpoints (localhost) and URLs that require authentication headers will not work. Check that your Slack webhook URL or endpoint is correct and returns a 2xx response. The alertSent field in the summary row will be false if delivery failed.

Run is taking longer than expected. Each actor in the input list triggers 4-5 API calls. A list of 50 actors can take 5-10 minutes depending on API response times. Reduce the list size or split it across multiple runs if you need results faster.

Success rate signals are not appearing for a known bad actor. The success rate check requires at least 5 runs in the actor's run history accessible by your token. Actors with very low usage or restricted run visibility will show Insufficient run data and produce no success rate signal, regardless of actual run quality.

Responsible use

• This actor only accesses publicly available actor metadata and your own run statistics via the official Apify API.
• It does not scrape actor Store pages or access any data outside the Apify REST API's intended scope.
• All API calls are made with the token you provide and respect the access controls that token has configured.
• For guidance on API usage terms, see the Apify Terms of Service.

FAQ

How does Actor Deprecation Monitor detect when an actor is being abandoned? It checks 7 signals: explicit deprecation flags, maintenance status, build staleness across three time windows, version update recency, success rate trends across the last 100 runs, abnormally high pricing, and developer activity across all their public actors. Each signal carries a weighted score and the total indicates how likely the actor is to stop working or be discontinued.

How is this different from Actor Health Monitor? Actor Health Monitor watches your own actors for runtime failures, success rate drops, and run count changes. Actor Deprecation Monitor watches third-party actors that you depend on but do not control. They serve complementary roles: one for your pipeline's internal health, one for its external dependencies.

How many actors can I monitor in one run? There is no hard limit built into the actor. Practical limits come from your spending cap and run timeout (1 hour by default). At roughly 3-5 seconds per actor for API calls, a timeout of 3600 seconds can handle 500+ actors. Set a spending limit to stop at your preferred budget.

How accurate is the risk score? The score reflects the weight of observable signals, not a prediction with known accuracy. It is a triage tool: CRITICAL scores reliably indicate multiple co-occurring problems, while HEALTHY scores mean no signals were detected. A HEALTHY score does not guarantee the actor will continue working — it means no detectable warning signs exist today.

Can I monitor actors I do not own? Yes. Any public actor on the Apify Store can be monitored by passing its username/actor-name slug. The actor uses the Apify public API endpoints which any valid token can access for public actors.

How often should I run this actor? Daily for actors in production pipelines. Weekly for staging or low-priority dependencies. A monthly scan is enough for actors you use occasionally. The Apify Scheduler makes it easy to set any cadence.

Does this actor work with private actors? Only if your API token has read access to that actor's metadata, builds, and runs. Private actors owned by other users are not accessible regardless of token unless the owner has explicitly shared access.

What should I do when an actor reaches CRITICAL status? Review the alternatives field in the output for replacement candidates. Test one against your actual pipeline inputs before migrating. Check the actor's Store page for any comments or changelog entries from the developer explaining the situation. Begin the migration immediately — CRITICAL scores typically precede complete failure within days to weeks.

Can I use the webhook output with Slack? Yes. Create a Slack incoming webhook URL from your workspace settings and paste it into the webhookUrl field. The POST payload includes the actor names, risk scores, risk levels, and top signals, which Slack will display as plain text in the channel.

Is it legal to monitor other developers' actors on the Apify Store? Yes. This actor uses only the official Apify REST API to read publicly available metadata — build dates, run statistics, pricing, and developer information. This is the same data visible to any user browsing the Store. No private data is accessed, and the API access is within the standard use of any Apify API token.

What happens if an actor ID in my list does not exist? The actor catches the error, pushes a report for that item with a riskScore of -1 and a descriptive error signal, and continues checking the remaining actors in your list. The run does not abort on individual failures.

Can I schedule this actor to run automatically? Yes. Open the actor in the Apify Console, click the Schedule tab, and set a cron expression. A daily run at 07:00 UTC (before business hours in most time zones) ensures your team starts the day with an up-to-date risk report. Combine with the webhook to push alerts to Slack automatically.

Help us improve

If you encounter issues, you can help us debug faster by enabling run sharing in your Apify account:

1. Go to Account Settings > Privacy
2. Enable Share runs with public Actor creators

This lets us see your run details when something goes wrong, so we can fix issues faster. Your data is only visible to the actor developer, not publicly.

Support

Found a bug or have a feature request? Open an issue in the Issues tab on this actor's page. For custom solutions or enterprise integrations, reach out through the Apify platform.