Apify Standby Mode: turn any Actor into a real-time API

Contains affiliate links. Disclosure.

Quick answer

Apify Standby Mode keeps an Actor running between requests, reducing cold-start latency for high-frequency, API-style Actor calls. You enable it on the Actor, expose an HTTP server on the configured port, and Apify routes authenticated traffic to your process until idle timeout shuts it down.

Create an Apify account · Console → Actors

Standard Actors follow start → work → stop (see the Actor programming model). That model is ideal for large crawls and batch jobs, but each new run pays a cold start (container boot, dependency init, browser launch if applicable). Standby Mode flips the model: one long-lived run serves many HTTP requests, similar to keeping a small service warm for your product or integration. The result behaves like a synchronous endpoint you call from the Apify API or any HTTP client.

Behavior and limits described here follow Apify’s Standby documentation. Always confirm current defaults in the Console.

What Standby mode is

Standard run	Standby mode
New container (or scale-out) per run	Same process handles many requests
Cold start on every run	Warm path after the first boot
One input payload per run	Many HTTP requests per run
Great for batch scrapes	Great for synchronous APIs and bursty traffic

In Standby, your Actor:

1. Starts once (per “standby run” lifecycle).
2. Listens on a port for HTTP traffic (you implement the server).
3. Answers requests without relaunching the whole Actor for each call.
4. Scales according to Apify’s Standby settings (concurrency / requests per run; see your Actor’s Standby tab for the knobs available to you).

When to use Standby mode

• Low-latency scrape APIs: your app sends a URL (or job id) and needs HTML, JSON, or a screenshot back in sub-second to low-second time once warm.
• Enrichment at submit time: forms or CRM workflows that block on a single page fetch or headless check.
• Webhook or integration front door: you accept a POST, do a small browser or HTTP task, and return 200 with a compact JSON body.
• High churn, small units of work: many tiny jobs per hour where cold starts would dominate wall time.
• MCP and AI-agent backends: an agent (or an MCP server) calls your Actor as a tool and waits for the answer inline. A warm standby endpoint returns data fast enough to keep the agent loop responsive instead of stalling on a fresh run each turn.

Prefer standard runs for huge crawls, long sequential queues, or rare invocations (nightly jobs). Standby shines when request frequency × cold-start pain is high.

When not to use it

• Cost-sensitive, sparse traffic: you pay for the time the standby run stays up; idle timeout mitigates this but does not eliminate it.
• Very long single jobs: a standard dedicated run is easier to reason about than multiplexing unrelated long tasks on one server.
• No HTTP surface: if your Actor is purely “read input, crawl, exit,” you would need to add an HTTP layer explicitly for Standby.

How to enable Standby mode

1. Implement an HTTP server in the Actor

If you are starting a new Actor, scaffold it first (see build an Apify Actor), then add the HTTP layer. Bind to the port Apify provides via Actor.config.get('standbyPort') (override with ACTOR_WEB_SERVER_PORT if you can't change your server's default). In Python the equivalents are Actor.configuration.standby_port and Actor.configuration.web_server_port. Handle the readiness probe (GET / with header x-apify-container-server-readiness-probe) with an early return so the platform marks the run ready without hitting your real handler.

import { Actor } from "apify";
import http from "http";

await Actor.init();

const server = http.createServer(async (req, res) => {
  if (req.headers["x-apify-container-server-readiness-probe"]) {
    res.writeHead(200);
    res.end("ready");
    return;
  }

  const url = new URL(req.url, `http://${req.headers.host}`);
  const targetUrl = url.searchParams.get("url");

  if (!targetUrl) {
    res.writeHead(400, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ error: "Missing 'url' parameter" }));
    return;
  }

  const response = await fetch(targetUrl);
  const html = await response.text();

  res.writeHead(200, { "Content-Type": "application/json" });
  res.end(
    JSON.stringify({
      url: targetUrl,
      title: html.match(/<title>(.*?)<\/title>/)?.[1] ?? "",
      contentLength: html.length,
    }),
  );
});

server.listen(Actor.config.get("standbyPort"));

Dual-mode Actors

A Standby Actor can still be started as a normal one-shot run (Console, schedule, or API). Branch on Actor.config.get('metaOrigin'): when it equals 'STANDBY', boot the HTTP server; otherwise run your batch code path. This avoids two separate Actors for the same logic.

2. Turn on Standby in the Console

1. Open the Actor → Settings (or the Standby tab, depending on UI version).
2. Enable Standby mode.
3. Configure idle timeout (how long to stay up without traffic), memory, and request limits as documented for your account tier.

Shorter idle timeouts save money; longer timeouts reduce repeated cold starts for sporadic traffic.

3. Call the public URL

Apify exposes a hostname for the standby endpoint (shown on the Actor or Task). Example:

curl -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  "https://<actor-hostname>/?url=https://example.com"

You can also pass ?token= instead of the header. Use the same API tokens you use for the Apify API.

Inside the Actor, read your own public hostname from the ACTOR_STANDBY_URL environment variable (or Actor.config.standbyUrl in the SDK) rather than hardcoding it.

4. Readiness probe

Apify sends GET / with the header x-apify-container-server-readiness-probe before routing real traffic. If you don't respond, the run is never marked ready and no requests come through. The snippet above short-circuits the probe with a 200 "ready" before touching any crawling logic.

Cost implications

Standby uses the same compute unit (CU) model as normal runs, but wall-clock uptime is the lever: a standby run that stays alive waiting for requests consumes resources for that whole period.

Practical cost controls:

• Tight idle timeout: shut down quickly when traffic stops.
• Right-size memory: more RAM increases CU burn; use the smallest footprint that keeps your browser or worker stable.
• Watch the usage chart: compare a week of Standby vs. the same workload as discrete runs (compute units).

For bursty but infrequent traffic, Standby can still win if each burst would otherwise trigger many cold starts; for one call per day, a standard run is usually cheaper.

If you publish a paid Standby Actor, Apify recommends the pay-per-event monetization model, which prices each request rather than raw uptime and maps cleanly onto an API-style endpoint (see monetize Actors).

Standby vs. standard runs (summary)

Topic	Standard	Standby
Latency	Higher per invocation (cold start)	Lower after warm
Model	One run, one job	Many HTTP requests per run
Scaling	You scale by parallel runs	Platform scales Standby per docs
Billing driver	Run duration × resources	Same, but idle time matters more

Limits to know

• First-response timeout: 5 minutes to receive the first response for a request.
• Run selection timeout (internal): 2 minutes for the platform to pick a run for your traffic.
• Per-account request rate: subject to Apify’s standard API rate limits. Verify current high-QPS ceilings in the Standby docs before planning heavy throughput.

FAQ

Frequently Asked Questions

Standby Mode keeps an Actor process running so it can handle many HTTP requests in a row without a full cold start each time, which is useful for API-style scraping or enrichment.

Use Standby when you need low latency and many small requests. Use standard runs for large crawls, rare schedules, or jobs that do not map cleanly to an HTTP request/response cycle.

Add an HTTP server to your Actor, bind to the Standby port from configuration, then enable Standby in the Actor settings and tune idle timeout and memory.

Billing uses the same compute units, but Standby can cost more if the process stays alive during idle periods. Shorter idle timeouts and smaller memory reduce that waste.

Send Authorization: Bearer YOUR_APIFY_TOKEN or append ?token= to the URL.

The first response must be sent within 5 minutes or the request times out.

Standby traffic is governed by Apify's standard per-account API rate limits. If you plan high queries per second, confirm the current ceilings in Apify's official Standby documentation before launch.

Apify issues GET / with the header x-apify-container-server-readiness-probe. Respond promptly so the load balancer marks your instance ready.

Yes. Tasks can have their own Standby hostname when you override Standby settings on the Task.

Yes. A warm Standby endpoint answers tool calls inline, so an agent or MCP server gets data back quickly instead of waiting for a fresh Actor run each turn.

Read the ACTOR_STANDBY_URL environment variable, or Actor.config.standbyUrl in the SDK, instead of hardcoding the hostname.

Apify recommends the pay-per-event model for Standby workflows, since it prices individual requests rather than raw uptime, which suits an API-style endpoint.