Standby Mode

Apify Standby Mode is a persistent deployment mode where an actor stays running continuously and listens for incoming HTTP requests, behaving like a traditional always-on web server rather than a batch job. In normal mode, every actor invocation starts a fresh Docker container (cold start of 2-10 seconds), processes the input, writes output, and shuts down. In Standby Mode, the container stays warm and handles multiple incoming HTTP requests from a single long-lived process with sub-second response times and zero cold start latency. Standby Mode matters because certain use cases require low-latency, always-available responses that are incompatible with the batch job model. MCP servers that serve AI agent tool calls need to respond in under 1 second — a 5-second cold start makes the AI agent appear sluggish and degrades user experience. Webhook processors need to acknowledge incoming webhooks immediately to avoid timeout retries from the sending service. API-style actors that serve data to front-end applications need consistent response times. Real-time monitoring dashboards that poll for updates need instant responses. All of these use cases are best served by Standby Mode. To enable Standby Mode, configure it in your .actor/actor.json file: { 'standby': { 'mode': 'development' or 'production', 'build': 'latest', 'memoryMbytes': 1024, 'idleTimeoutSecs': 600 } }. Then implement an HTTP server in your actor code: import express from 'express'; import { Actor } from 'apify'; Actor.main(async () => { const app = express(); app.get('/health', (req, res) => res.json({ status: 'ok' })); app.post('/api/scrape', async (req, res) => { const result = await scrape(req.body.url); res.json(result); }); const port = process.env.ACTOR_STANDBY_PORT || 3000; app.listen(port); console.log('Standby server running on port ' + port); }); Apify routes incoming requests to your actor's HTTP port via the URL https://your-actor.apify.actor/api/scrape and keeps the container alive between requests. The idleTimeoutSecs parameter controls how long the actor stays alive without receiving a request. Set it to 300-3600 seconds depending on your traffic pattern. If no request arrives within the idle timeout, Apify shuts down the container to save costs. The next incoming request triggers a cold start to spin up a new container. For high-traffic actors, the idle timeout rarely triggers because requests keep the container alive continuously. Common mistakes with Standby Mode include enabling it for batch scrapers that run once per day or on a schedule. A 1 GB actor running in Standby Mode 24/7 costs 24 CU per day ($6/day or $180/month) in compute, regardless of how many requests it serves. If your actor only processes a few requests per day, the per-request cost is astronomical compared to normal mode where you pay only for actual processing time. Use Standby Mode when your actor receives at least several requests per hour to amortize the always-on cost. Another mistake is not implementing health checks. Apify monitors standby actors and restarts them if they become unresponsive. Implement a /health endpoint that returns 200 OK so the platform can verify your actor is alive. Not handling graceful shutdown is also problematic: when Apify scales down or restarts your actor, it sends a SIGTERM signal. Listen for this signal and finish processing any in-flight requests before exiting: process.on('SIGTERM', async () => { await server.close(); process.exit(0); }). Standby Mode costs are visible in the Apify Console under Usage, broken down by actor and time period. For MCP servers and API actors that need to be always available, Standby Mode is the only viable option on Apify. For everything else — scheduled scrapes, one-off data extraction, batch processing — stick with normal mode. Related concepts: MCP Server, Actor Run, Compute Unit, Actor Build, Webhook.