apify-prod-checklist

v2026.09.24

Production readiness checklist for Apify Actor deployments. Use when deploying an Actor to production, preparing for launch, or validating Actor configuration, scheduling, monitoring, and rollback before going live. Trigger with "apify production", "deploy actor to prod", "apify go-live", "apify launch checklist", "actor production ready".

GitHub
安装命令
npx skhub add jeremylongshore/apify-prod-checklist
Markdown
SKILL.md

Apify Production Checklist

Overview

Complete checklist for deploying Actors to the Apify platform and integrating them into production applications. Covers Actor configuration, scheduling, monitoring, alerting, and rollback. Work top to bottom: clear the pre-deployment gates, then run the six deploy steps, then wire the alert conditions.

Prerequisites

  • Actor tested locally with apify run
  • apify login configured with production token
  • Familiarity with apify-core-workflow-a and apify-deploy-integration

Pre-Deployment Checklist

Actor Configuration

  • .actor/actor.json has correct name, title, description
  • INPUT_SCHEMA.json validates all required inputs
  • Dockerfile uses pinned base image version (apify/actor-node:20, not latest)
  • package-lock.json committed (deterministic installs)
  • Memory set appropriately (start at 1024MB, tune after profiling)
  • Timeout set with buffer (2x expected runtime)

Code Quality

  • Actor.main() wraps entry point (handles init/exit/errors)
  • failedRequestHandler logs failures without crashing Actor
  • Input validation at Actor start (if (!input?.startUrls) throw ...)
  • No hardcoded URLs, credentials, or magic numbers
  • Proxy configured for target sites that block datacenter IPs
  • maxRequestsPerCrawl set to prevent runaway costs

Data Output

  • Dataset schema documented (consistent field names)
  • SUMMARY key-value store record saved with run stats
  • Large payloads chunked (9MB dataset push limit)
  • PII sanitized before storage

Instructions

Read the Actor's .actor/actor.json, INPUT_SCHEMA.json, and Dockerfile first to confirm the pre-deployment gates above, then run the six deploy steps. Each step's full command and code block lives in references/implementation.md; the skeleton is below.

  1. Deploy Actor — apify push, then apify builds ls to confirm the build, then apify actors call with a small production-like input to smoke-test on-platform.
  2. Configure Scheduling — create a cron schedule with client.schedules().create({...}) (or Apify Console: Actors > Your Actor > Schedules). Set cronExpression, runInput, and runOptions (memory/timeout).
  3. Set Up Webhooks — client.webhooks().create({...}) on ACTOR.RUN.SUCCEEDED/FAILED/TIMED_OUT with a payloadTemplate posting runId, status, and datasetId to your server.
  4. Monitor Runs — a checkActorHealth(actorId, lookbackHours) helper lists recent runs and reports success rate, failures, timeouts, and total cost.
  5. Implement Rollback — apify builds ls, then repoint the Actor at a prior build via the POST /v2/acts/ACTOR_ID?build=N API, or redeploy from a git tag.
  6. Cost Guard — runWithCostGuard(actorId, input, maxCostUsd) polls usageTotalUsd every 30s and aborts the run if it exceeds budget.

The first deploy step in full:

# Build and push to Apify platform
apify push

# Verify the build succeeded
apify builds ls

Output

Working through this skill produces a production-ready Actor with:

  • A pushed, verified build (apify builds ls shows a SUCCEEDED build).
  • A live cron schedule and a completion webhook firing on success/failure/timeout.
  • A repeatable health check printing success rate, failure/timeout counts, and 24h cost.
  • A tested rollback path (build repoint or git-tag redeploy).
  • A cost guard that aborts runs exceeding budget.

Health-check output looks like:

Actor: username/product-scraper
Last 24h: 3 runs, 66.7% success
Failed: 1, Timed out: 0
Total cost: $0.4213

Production Alert Conditions

AlertConditionSeverity
Run failedstatus === 'FAILED'P1
Run timed outstatus === 'TIMED-OUT'P2
Low yieldDataset items < expected thresholdP2
High costusageTotalUsd > budgetP2
Consecutive failures3+ failures in a rowP1
No runs in windowSchedule didn't triggerP1

Error Handling

IssueCauseSolution
Build fails on platformLocal deps differCommit package-lock.json
Schedule not firingCron syntax errorValidate at crontab.guru
Webhook not receivedURL not reachableUse ngrok for testing; check HTTPS
Memory exceededWorkload too largeIncrease memory or reduce concurrency
Unexpected cost spikeNo maxRequestsPerCrawlAlways set an upper bound

Examples

Four worked examples — a first production deploy, health-check output, a cost guard aborting a runaway run, and a build rollback — are in references/examples.md. A first production deploy in brief:

# Smoke-test on-platform with a tiny input before scheduling
apify actors call username/product-scraper \
  --input='{"startUrls":[{"url":"https://target.com"}],"maxItems":10}'

Then create the daily schedule and completion webhook (implementation.md Steps 2–3).

Resources

Next Steps

Once production is stable, plan version upgrades with the apify-upgrade-migration skill: it covers bumping the Actor base image, migrating INPUT_SCHEMA.json fields without breaking existing schedules, and re-running this checklist against the new build before repointing traffic.

发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

Sep 24, 2026

分类

未分类

许可证

MIT

源路径

skills/.curated/apify-prod-checklist

默认分支

main

最新提交

e5a6c3b

Tree SHA

c2dc8e8