Apify Actor Exit Codes: What They Mean and How to Diagnose Them

Apify actor exit codes tell you how and why an actor run ended. Exit code 0 means success. Exit code 91 means your code threw an unhandled exception. Exit code 137 means the actor ran out of memory. This page covers every common exit code, what causes it, how to fix it, and how ApifyForge Monitor uses exit codes to give you instant diagnostics in your failure alerts.

Exit code reference table

Exit code 0: Success

Exit code 0 means the actor completed without errors. The run finished, all data was pushed to the dataset, and the actor exited cleanly. No action needed.

In ApifyForge Monitor, exit code 0 appears when you track ACTOR.RUN.SUCCEEDED events (available on Developer and Pro plans). This is useful for SLA tracking and confirming critical pipeline runs.

Exit code 1: Unhandled error

Exit code 1 indicates a generic process error. This usually happens when an exception occurs outside the Actor.main() wrapper — for example, in a top-level import or a module initialization error.

How to fix: Ensure all your logic runs inside Actor.main(). Check for syntax errors, missing dependencies, and failing top-level imports. Review the run log in the Apify console for the specific error message.

Exit code 91: Actor error (thrown exception)

Exit code 91 is the most common failure code. It means your actor code threw an exception inside Actor.main() that was not caught by a try-catch block. The Apify SDK catches it, logs the error, and exits with code 91.

Common causes:

• Network request failures (API rate limits, DNS resolution, connection timeouts)
• Invalid input that is not validated before use
• Null pointer errors when accessing properties on undefined objects
• Web scraping selector changes (target site updated its HTML)
• Third-party API authentication failures

How to fix: Check the error message in the run log or in your ApifyForge Monitor alert. The message usually points directly to the failing line. Add error handling around network requests, validate input early, and use optional chaining for DOM selectors.

Exit code 137: Out of memory (OOM killed)

Exit code 137 means the Linux kernel's OOM killer terminated the process because it exceeded its memory allocation. This is one of the most common and most frustrating failure modes for Apify actors.

Common causes:

• Loading an entire dataset into memory instead of streaming
• Unbounded arrays that grow with each page of results
• Memory leaks in long-running crawlers (event listeners not cleaned up)
• Processing large files (PDFs, images) without streaming
• Using too-small memory allocation for the workload

How to fix:

1. Increase the actor's memory allocation in the Apify console or actor.json
2. Use streaming instead of loading full datasets into memory
3. Push results to the dataset incrementally instead of accumulating in an array
4. For crawlers, limit concurrency to reduce peak memory usage
5. Check for memory leaks with the --inspect flag during local testing

ApifyForge Monitor shows exit code 137 as "Out of memory (OOM killed)" in the diagnostic label, so you know immediately to check memory usage rather than looking for code bugs.

Exit code 143: Graceful shutdown (SIGTERM)

Exit code 143 means the actor received a SIGTERM signal and exited gracefully. This is not always an error — it can be normal behavior in several situations.

Common causes:

• The user manually aborted the run from the Apify console
• The run exceeded its configured timeout and was stopped by the platform
• Apify's infrastructure scaled down the container (rare)
• The actor handled the SIGTERM signal and shut down cleanly

How to fix: If the actor timed out, increase the timeout setting or optimize the actor to complete faster. If it was manually aborted, no fix is needed. If you are seeing unexpected SIGTERM exits, check if the actor's timeout is too short for its workload.

Exit code 255: Platform error

Exit code 255 means an internal Apify platform error occurred. This is not caused by your code — it is an infrastructure issue on Apify's side.

Common causes:

• Docker container startup failure
• Apify platform outage or degraded service
• Resource allocation issues on the Apify cloud

How to fix: Exit code 255 is not fixable from the developer side. Retry the run. If it persists, check the Apify status page and contact Apify support. ApifyForge Monitor labels this as "Internal platform error" so you know not to waste time debugging your own code.

How ApifyForge Monitor uses exit codes

On the Developer ($9/month) and Pro ($29/month) plans, ApifyForge Monitor includes the exit code and a human-readable diagnostic label in every failure alert. Instead of seeing just "FAILED," you see:

• FAILED (exit 91 — Actor error) — check your code
• FAILED (exit 137 — Out of memory) — increase memory allocation
• FAILED (exit 143 — Graceful shutdown) — check timeout settings
• FAILED (exit 255 — Platform error) — retry or contact Apify

This instant triage saves you from opening the Apify console to figure out what kind of failure occurred. You know the category immediately and can act accordingly.

Using exit codes with setStatusMessage

Combine exit codes with Actor.setStatusMessage() for maximum diagnostic value. The exit code tells you the failure category, and the status message tells you the specific context:

await Actor.setStatusMessage('Processing page 47 of 200 — api.example.com/v2/search');

// If this crashes with exit 137, your alert shows:
// FAILED (exit 137 — Out of memory)
// Error: Processing page 47 of 200 — api.example.com/v2/search
// Now you know: OOM at page 47 → memory grows with each page → need streaming

For setup instructions, see the Setup Guide. For information on customer-run failure alerts, see Customer Run Failures.

Last updated: March 2026