[docs] Document ASPIRE_CLI_START_TIMEOUT environment variable

src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx

@@ -52,6 +52,19 @@ If graceful shutdown is taking too long and you need to exit immediately, press
 On Windows, TypeScript/JavaScript AppHosts started with `tsx` or `npm` run in an isolated console session so that the Ctrl+C signal is delivered correctly to the Node.js process rather than to an unrelated foreground window.
 :::
 
+## Configuring the startup timeout
+
+`aspire run` waits for the AppHost to reach a stable running state before it considers startup complete. If the AppHost build or startup takes longer than the default 120-second window—for example on a slow machine or in a CI environment—set the `ASPIRE_CLI_START_TIMEOUT` environment variable to a higher number of seconds:
+
+```bash title="Aspire CLI"
+export ASPIRE_CLI_START_TIMEOUT=300
+aspire run
+```
+
+If `ASPIRE_CLI_START_TIMEOUT` is set to a value that isn't a positive whole number of seconds, `aspire run` displays an error and exits without starting the AppHost. This behavior also applies to `aspire run --detach` and to `aspire start`.
+
+`ASPIRE_CLI_START_TIMEOUT` controls how long `aspire run` and `aspire start` wait for the AppHost to start. It's separate from `aspire wait --timeout`, which controls how long `aspire wait` waits for an individual *resource* inside an already-running AppHost to reach a target status.
+
 ## Hot Reload and watch behavior
 
 By default, `aspire run` starts the distributed application once. It doesn't watch the AppHost or resource source files. After you change AppHost code, stop the running AppHost with <Kbd windows="Ctrl+C" mac="⌃+C" linux="Ctrl+C" />, and then run `aspire run` again. For individual resource changes, keep the AppHost running and restart or rebuild the resource from the Aspire CLI or dashboard when needed.

src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx

@@ -60,6 +60,17 @@ The parent log also captures the replayed child output under `DetachedAppHost/..
 
 Pressing <Kbd windows="Ctrl+C" mac="⌃+C" linux="Ctrl+C" /> while `aspire start` is waiting for the AppHost to start will terminate the startup process.
 
+### Configuring the startup timeout
+
+`aspire start` waits up to 120 seconds by default for the AppHost to reach a stable running state. If the AppHost build or startup takes longer than that—for example on a slow machine or in a CI environment—set the `ASPIRE_CLI_START_TIMEOUT` environment variable to a higher number of seconds:
+
+```bash title="Aspire CLI"
+export ASPIRE_CLI_START_TIMEOUT=300
+aspire start
+```
+
+If `ASPIRE_CLI_START_TIMEOUT` is set to a value that isn't a positive whole number of seconds, `aspire start` displays an error and exits without starting the AppHost. This behavior also applies to `aspire run`, including `aspire run --detach`.
+
 ## Hot Reload and watch behavior
 
 By default, `aspire start` starts the AppHost as a detached background process. It doesn't watch the AppHost or resource source files. After you change AppHost code, restart the detached AppHost by running `aspire start` again. For individual resource changes, keep the AppHost running and restart or rebuild the resource from the Aspire CLI or dashboard when needed.

src/frontend/src/content/docs/reference/cli/commands/aspire-wait.mdx

@@ -20,6 +20,8 @@ aspire wait <resource> [options]
 
 The `aspire wait` command blocks until a named resource within a running AppHost reaches a target status. This is useful for CI/CD pipelines and automation workflows where you need to wait for resources to be ready after starting an AppHost with `aspire run --detach`.
 
+The `--timeout` option here controls how long to wait for a *resource* to reach its target status. It's separate from the `ASPIRE_CLI_START_TIMEOUT` environment variable, which controls how long `aspire run` and `aspire start` wait for the *AppHost itself* to finish starting up. See [aspire run](/reference/cli/commands/aspire-run/#configuring-the-startup-timeout) for details.
+
 The command connects to a running AppHost via the backchannel and streams resource state changes in real-time. It validates that the specified resource exists before entering the wait loop, so typos in resource names are caught immediately rather than causing a silent timeout.
 
 When executed without the `--apphost` option, the command: