Actor Standby mode

A standard Actor runs a single job and then stops. It works great for batch jobs, such as a large data extraction or processing task. However, some applications can't wait for an Actor to start. In Standby mode, the Actor stays ready in the background and serves incoming HTTP requests in real time, like a web server or an API server.

To build your own Standby Actor, see Develop Actors in Standby mode.

Check if an Actor supports Standby mode

If an Actor has Standby mode enabled, its detail page shows the Server tab. The tab contains the hostname of the Actor's server, and the Actor README describes the endpoints, the parameters they accept, and what they return. If the Actor defines a web server schema, the tab also shows an interactive list of its endpoints, where you can send requests directly from the browser.

You don't need to start the Actor. Send a request to that hostname and endpoint, and you get the results.

Standby URLs

The Standby URL typically combines the Actor owner's username and the Actor name, for example:

https://jane-doe--my-actor.apify.actor

The Actor also responds on a URL built from its ID, which keeps working if the Actor or its owner is renamed:

https://92c4oi4fpzy7rprlf.apify.actor

The Standby URL stays the same for all runs of the Actor, so you can share it publicly or hardcode it in applications that call the Actor. Copy the URL from the Server tab instead of building it from the username and Actor name, because some Actors use a different hostname format, like rag-web-browser.apify.actor.

Send requests to the Actor

If you use an Actor built by someone else, its README describes how to pass the input.

Actors in Standby mode behave as standard HTTP servers. Use any HTTP request method, such as GET, POST, PUT, or DELETE, and pass the input in the query string or the request body.

Authenticate requests

Authenticate Standby requests the same way as requests to the Apify API. Provide your API token in one of two ways:

(Recommended) Include the token in the Authorization header as Bearer <token>. This keeps the token out of server logs.
```
curl -H "Authorization: Bearer my_apify_token" \
  https://rag-web-browser.apify.actor/search?query=apify
```
Append the token to the request URL as the token query parameter. It's less secure, so use this option only when you can't modify the request headers.
```
https://rag-web-browser.apify.actor/search?query=apify&token=my_apify_token
```

The platform removes the token from the request before forwarding it, so the token doesn't reach the Actor's code. If the Actor reads the Authorization header for its own authentication, send your Apify token in the X-Apify-Authorization header instead.

Scoped tokens work for Standby requests. To let a third-party service call your Actor without access to your entire account, give it a scoped token with only the permissions it needs.

Restricted access is not supported

A scoped token also has a restricted access option that limits what the Actor's run can access. Standby mode doesn't support that option.

If you're developing a Standby Actor, use the token from the APIFY_TOKEN environment variable to call the Apify API, as in any other Actor.

Run the Actor in standard mode

If the Actor has an input schema, you can modify the input in the Input tab and select Start to run the Actor in standard mode. If the Actor has no input schema, Apify Console disables the Input tab. Not every Standby Actor supports standard mode. If it doesn't, the run might fail, return empty results, or start in Standby mode. Check the Actor README for what the Actor supports.

Limits and scaling

The platform scales Standby runs automatically and applies timeouts and rate limits to the incoming requests.

Automatic scaling

The platform scales the Actor to match the incoming requests. It starts new Actor runs, which appear in the Actor Runs tab with the origin set to Standby.

The runs that serve your requests aren't shared with other users, even when you use the Actor-level hostname with the default configuration.

The platform checks a run's readiness once, before the run starts serving requests, and performs no health checks after that.

Unresponsive servers aren't detected

If an Actor's server stays up but stops responding, the platform doesn't detect the failure, and requests keep going to that run. To learn how to handle this situation in your own Actors, see Run lifecycle.

Request timeouts

A request to a Standby Actor must receive its first response within 5 minutes. This is the overall timeout for the request.

Within this window, the platform first selects an Actor run to handle the request, which can take up to 2 minutes, for example when a new run needs to start. If no run becomes available within that time, the request fails with a 429 error.

Rate limits

The platform rate-limits incoming requests to Standby Actors per user account. The limit is the same on all standard subscription plans, and custom plans can raise it. Responses include the current limit in the X-RateLimit-Limit header. When you exceed the limit, the platform responds with a 429 Too Many Requests error.

Standby configuration

The Standby configuration has these properties:

Property	Description
Max requests per run	The maximum number of concurrent HTTP requests a single Standby Actor run can accept. When a request exceeds this limit, the platform starts a new run to handle it, which can take a few seconds.
Desired requests per run	The number of concurrent HTTP requests a single Standby Actor run is configured to handle. When requests exceed this number, the platform starts a new run ahead of time to handle the additional requests.
Memory (MB)	The amount of memory (RAM) allocated for the Actor in Standby mode, in megabytes. More memory usually lets the Actor handle more requests in parallel, but it also consumes more compute units and costs more.
Idle timeout (seconds)	If a run receives no HTTP requests within this time, the platform stops it. The next request might then need a new run, which can take a few seconds to start. A higher idle timeout improves responsiveness but costs more, because the run stays active longer.
Build	The Actor build that Standby runs use: a build tag (for example `latest`) or a build number (for example `0.1.2`).
Validate and pass Actor input	If enabled, the platform validates the Actor input and passes it to the run even when the run starts in Standby mode. Use it to start Standby runs with different configurations. If disabled, the input applies only to manual runs and testing, independent of Standby mode.

If you own the Actor, you can see and change its default Standby configuration in the Settings tab.

Override the configuration with a task

If you use an Actor built by someone else, the Actor-level hostname always uses the developer's default configuration. To override it:

In Apify Console, open the Actor and select Save as a new task.
Open the task's Settings tab.
Modify the configuration.
In your application, use the task's hostname instead of the Actor's.

Developers can lock the configuration

If the developer locked the Standby configuration, the task-level settings have no effect.

Billing

The platform bills Standby runs like standard runs. A Standby run also consumes resources while it waits for requests, until the idle timeout stops it. Expect usage even when no requests arrive.

For Actors monetized with the pay-per-event pricing model, you pay the platform usage costs of the Standby runs in addition to the event charges.

Use Standby Actors as MCP servers

If the Actor exposes a Model Context Protocol (MCP) server, its MCP endpoint is the Standby URL followed by the path defined in the Actor's webServerMcpPath property. Apify Console shows the MCP URL in the Actor's Server tab. Authenticate requests to the MCP endpoint the same way as any other Standby request.