Repository navigation
docs: restructure the Standby pages with topic-based headings - #3107
Conversation
Replaces the FAQ-style question headings with the topic structure used by sibling pages, moves the Standby URL section to the user page, and gives each duplicated fact a single owner with cross-links.
Plain-language pass after the restructure: active voice, shorter sentences, one term per concept. Facts and structure unchanged.
|
🗑️ Preview for this PR was deleted. |
mixalturek
left a comment
There was a problem hiding this comment.
Nicely written, the comments are mainly nitpicks, no need to apply everything :-)
I only wonder why we are updating the docs so heavily just before the multi-tenant release and rebranding to Server Actors. I expect a similar PR in a few weeks...
| To let third-party services call your Actor without access to your entire account, send Standby requests with [scoped tokens](/integrations/api#limited-permissions). | ||
|
|
||
| :::caution Restricted access is not supported | ||
|
|
||
| Standby mode doesn't support [restricting what an Actor can access](/integrations/api#restricted-access-restrict-what-actors-can-access-using-the-scope-of-this-actor) with a scoped token. |
There was a problem hiding this comment.
I didn't understand the message at first, and I had to read the original version to get it.
The first paragraph says I should use scoped tokens to limit access, but the second one says the scoped token doesn't support it 🙃 I think the main difference is the word "However", which slightly shifts the meaning, and emphasizes "entire account" vs. scopes and restricting of something different. I am not an expert in this area at all 😉
| ## Standby configuration | ||
|
|
||
| The Standby configuration currently consists of the following properties: | ||
| The Standby configuration has these properties: |
| | Build | The Actor build that Standby runs use: a build tag (for example `latest`) or a build number (for example `0.1.2`). | | ||
|
|
||
| You can see these in the **Endpoints** tab of the Actor detail page. If you own the Actor, you can change its default Standby configuration in the **Settings** tab. | ||
| You can see the current values in the **Endpoints** tab of the Actor detail page. If you own the Actor, you can change its default Standby configuration in the **Settings** tab. |
There was a problem hiding this comment.
Do you mean the Standby config above by "the current values"? I don't see them in the Endpoints tab 🤷♂️ Is it outdated?
Update: I see, it's meant for a task (### Override the configuration with a task below). I consider this info incorrect - only one of the tabs contains the info, the context matters here a lot.
|
|
||
| No, the Standby runs are billed in the same fashion as the normal runs. | ||
| However, running Actors in Standby mode might have unexpected costs, as the Actors run in the background and consume resources even when no requests are being sent until they are terminated after the idle timeout period. | ||
| 1. In [Apify Console](https://console.apify.com), create a new task from the Actor. |
There was a problem hiding this comment.
Isn't all this documentation in the context of Console? I would either remove this info or add the missing intermediate steps (find the actor...).
| :::note Developers can lock the configuration | ||
|
|
||
| The Actor's developer can lock the Standby configuration. In that case, the task-level settings have no effect. |
There was a problem hiding this comment.
The first sentence repeats the title.
| ## Billing | ||
|
|
||
| ## Can I use Standby Actors as MCP servers | ||
| The platform bills Standby runs like normal runs, but the costs can surprise you. A Standby run consumes resources in the background even when no requests arrive, until the idle timeout stops it. |
There was a problem hiding this comment.
Subjective: I read "..., but the costs can surprise you." between lines as "..., don't use it". Can we reword it to use "slightly higher" instead of a bad surprise?
There was a problem hiding this comment.
Reworded it to say what happens instead of how it feels: a Standby run keeps consuming resources while it waits for requests, so expect usage with no traffic. I left out "slightly higher" because nothing in the docs or code pins down the size of the difference.
| ## Use Standby Actors as MCP servers | ||
|
|
||
| See the [Actor Standby development section](../development/programming_interface/actor_standby.md). | ||
| If the Actor exposes a [Model Context Protocol (MCP)](../../agents/mcp.md) server, its MCP endpoint is the Standby URL followed by the path defined in the Actor's [`webServerMcpPath`](../development/actor_definition/actor_json.md) property. Authenticate requests to the MCP endpoint the same way as any other Standby request. |
There was a problem hiding this comment.
Outdated? The URL should be available in the Endpoints tab for some time.
tobice
left a comment
There was a problem hiding this comment.
Looks good, just noticed a few no longer accurate statements.
Just note that with multi-tenant, we might need to rethink the structure even more: Some information will apply to both while some only to one tenancy mode. Plus the assumption is that multi-tenant becomes the default, while single-tenant stays as a niche feature. The documentation should probably reflect that.
| Yes, you can still modify the input and click the Start button to run the Actor in normal mode. However, note that the Standby Actor might | ||
| not support this mode; the run might fail or return empty results. The normal mode is always supported in Standby Beta, even for Actors that don't handle | ||
| it well. Please head to the Actor README to learn more about the capabilities of your chosen Actor. | ||
| You can still modify the input and select **Start** to run the Actor in normal mode. The platform always allows it, but the Actor might not support it. The run might fail or return empty results. Check the Actor README for what the Actor supports. |
There was a problem hiding this comment.
We actually disable the Input tab if it is not supported.
| ## Determining an Actor is started in Standby | ||
| ### Run termination | ||
|
|
||
| A run ends when its process exits, when it migrates to another machine, or when it stays idle for longer than the idle timeout. Apart from the [readiness probe](#readiness-probe), the platform doesn't check your server's health while the run is alive. A server that stays up but stops responding keeps receiving requests, so on an unrecoverable error, exit the process instead of swallowing the error. |
There was a problem hiding this comment.
when it migrates to another machine
This is no longer true. Instead of migrating, we start a new run and then we abort the old run, making sure there is always at least one run handling requests.
|
Thanks for the review @mixalturek , the upcoming multitenant is precise why the docs needed to be updated. The structure I created here primes the docs for easier update in few weeks. Remaking of the headings, making prose easier etc are all necessary |
Co-authored-by: Michal Turek <[email protected]> Co-authored-by: Tobiáš Potoček <[email protected]>
Config values aren't shown on the Server tab, runs are replaced rather than migrated, and the pass-input setting was missing from the table.
|
@tobice Noted, thanks. The structure may change again once we sit down to the multi-tenant docs. |
Both show the old Standby tab and settings form, which the prose no longer matches, and neither carries anything the text doesn't.
7749d16 to
e8ec694
Compare
|
|
||
| You can enable Standby mode from a template, in Apify Console, or in the Actor's source code. | ||
|
|
||
| ### Start from a template |
There was a problem hiding this comment.
Hm, to me we're mixing concepts here a little and end up with wordy headings. I'd separate the info on templates and make it H2. What this paragraph is missing is also explicitly saying that it involves creating an Actor from a template. Something like this:
## Start with a template
## Enable Standby mode
### In Apify Console
### In the source code
Or keep the existing structure, but improve the info on templates and use another verb for H2, so it's not enable three times.
Co-authored-by: Edyta <[email protected]>
Split the template step from enabling Standby, and use one term, standard, for runs that aren't Standby.

Replaces the question-style headings on both Standby pages with topic headings and tightens the prose, so the pages stop reading as a FAQ. Facts are unchanged from #3032; in-repo links use the new anchors, and external links to the old
#how-do-i-…anchors fall back to the page top.