diff --git a/src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx b/src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx
index e58d9a048..67e252008 100644
--- a/src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx
+++ b/src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx
@@ -54,7 +54,7 @@ On Windows, TypeScript/JavaScript AppHosts started with `tsx` or `npm` run in an
 
 ## 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:
+`aspire run` waits for the AppHost to reach a stable running state before it considers startup complete. If the AppHost 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
@@ -63,6 +63,8 @@ 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` only bounds the time the AppHost takes to reach a stable running state after it starts executing. Restoring and building the AppHost project—including a required safety build performed for an explicit `--no-build`—doesn't count against this budget, so a long restore or build on a cold or large solution won't cause a misleading startup timeout. Once the build completes, the AppHost receives the full configured startup budget.
+
 `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
diff --git a/src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx b/src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx
index eef13509b..d3b814c78 100644
--- a/src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx
+++ b/src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx
@@ -62,15 +62,17 @@ Pressing <Kbd windows="Ctrl+C" mac="⌃+C" linux="Ctrl+C" /> while `aspire start
 
 ### 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:
+`aspire start` waits up to 120 seconds by default for the AppHost to reach a stable running state. If the AppHost 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
+```powershell title="Aspire CLI"
+$env:ASPIRE_CLI_START_TIMEOUT = "15"
+aspire start --no-build
 ```
 
 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`.
 
+`ASPIRE_CLI_START_TIMEOUT` only bounds the time the AppHost takes to reach a stable running state after it starts executing. The detached launcher doesn't consume this budget while its child process restores and builds, and a required safety build performed for an explicit `--no-build` runs before the budget begins. A required safety build can take longer than the configured timeout; once it completes, the AppHost receives the full startup budget.
+
 ## 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.