From ea8271303cb0541e78405b01e38f43bd924e8efc Mon Sep 17 00:00:00 2001 From: Kristin Martin Date: Tue, 20 Oct 2026 17:44:36 +0000 Subject: [PATCH] Fix the rendering and link problems from the meta description review The mechanical remainder of docs-tracking#370. scale-machine had two command blocks whose opening had landed inside the output fence, so the tag rendered as literal text and neither block became a code group. volume-manage wrapped two commands in literal backticks inside bash fences, so copying them gave broken shell. The autoscaling page sent both autostop/autostart links to the same page, and fly-proxy linked a path that only resolves through a redirect. request-headers credited headers to "the HTTP handler service" rather than Fly Proxy, and logs-api-options called the HTTP API undocumented on a page that documents its parameters. --- launch/scale-machine.mdx | 16 +++++++++------- monitoring/logs-api-options.mdx | 2 +- networking/request-headers.mdx | 2 +- reference/autoscaling.mdx | 2 +- reference/fly-proxy.mdx | 2 +- volumes/volume-manage.mdx | 6 +++--- 6 files changed, 16 insertions(+), 14 deletions(-) diff --git a/launch/scale-machine.mdx b/launch/scale-machine.mdx index f3a646aa72..7a2287570e 100644 --- a/launch/scale-machine.mdx +++ b/launch/scale-machine.mdx @@ -20,10 +20,11 @@ You can scale an app even if it has crashed. Its Machines are restarted with the Here's a simple web app with three Machines running in different regions: two in Toronto and one in Tokyo. All the app's Machines belong to the default process group, `app`, since no other [processes](/launch/processes) exist. -```bash + +```bash cmd fly status ``` -```out +```out out App Name = testrun Owner = personal @@ -35,8 +36,8 @@ PROCESS ID VERSION REGION STATE ROLE CHECKS LAST app 17811943f031d8 3 yyz stopped 1 total, 1 passing 2024-02-07T15:34:57Z app 328749d3c53958 3 yyz stopped 1 total, 1 passing 2024-01-23T19:39:50Z app 908057ef21e487 3 nrt started 1 total, 1 passing 2024-01-23T19:39:51Z - ``` + `fly scale show` shows the CPU and RAM settings for all the Machines deployed using `fly deploy` under this app. @@ -107,17 +108,18 @@ Scaled VM Type to 'shared-cpu-2x' Check that the `app` process group has had this scale applied: -```bash -fly scale show + +```bash cmd +fly scale show ``` -```out +```out out VM Resources for app: testrun Groups NAME COUNT KIND CPUS MEMORY REGIONS app 3 shared 2 512 MB nrt,yyz(2) - ``` + You can also confirm that an individual Machine's config matches this, using `fly machine status `: diff --git a/monitoring/logs-api-options.mdx b/monitoring/logs-api-options.mdx index 43471bfc50..07fa68c00a 100644 --- a/monitoring/logs-api-options.mdx +++ b/monitoring/logs-api-options.mdx @@ -18,7 +18,7 @@ But sometimes you want to grab logs directly, without a CLI or setting up an exp You can get logs programmatically via: -- **Undocumented HTTP API**: What `fly logs` uses under the hood. +- **HTTP API**: What `fly logs` uses under the hood. It isn't in the API reference, but its parameters are documented below. - **NATS proxy**: Subscribe to real-time logs at the message level. - **Log shipper to external sink**: Ingest logs elsewhere, then query them via that system. diff --git a/networking/request-headers.mdx b/networking/request-headers.mdx index 4ec84847d2..e2aa0ed9ec 100644 --- a/networking/request-headers.mdx +++ b/networking/request-headers.mdx @@ -6,7 +6,7 @@ source_url: https://fly.io/docs/networking/request-headers/ Illustration by Annie Ruygt of flying ghosts carrying lanterns -Request headers carry information that is specific to the incoming request and its path taken to the application. Request headers are added by the HTTP handler service. +Request headers carry information that is specific to the incoming request and its path taken to the application. Request headers are added by Fly Proxy. ## Request Headers diff --git a/reference/autoscaling.mdx b/reference/autoscaling.mdx index 89f3f90796..5685fd9bc9 100644 --- a/reference/autoscaling.mdx +++ b/reference/autoscaling.mdx @@ -15,7 +15,7 @@ Autoscaling adjusts the number of running or created Fly Machines dynamically. W Fly Proxy autostop/autostart starts and stops Machines based on load; Machines are never created or deleted. You create a "pool" of Machines in one or more regions and Fly Proxy starts and stops them as needed. -For details about how it works, see [Fly Proxy autostop/autostart](/launch/autostop-autostart). To configure autostop/autostart for your app, see [Autostop/autostart Machines](/launch/autostop-autostart). +For details about how it works, see [Fly Proxy autostop/autostart](/reference/fly-proxy-autostop-autostart). To configure autostop/autostart for your app, see [Autostop/autostart Machines](/launch/autostop-autostart). ## Metrics-based autoscaling diff --git a/reference/fly-proxy.mdx b/reference/fly-proxy.mdx index 1aeb16eb68..05c9fb65a9 100644 --- a/reference/fly-proxy.mdx +++ b/reference/fly-proxy.mdx @@ -51,7 +51,7 @@ Fly Proxy can start and stop existing Machines based on incoming requests, so th Fly Proxy uses the same concurrency settings for autostop/autostart as for load balancing to determine when Machines have excess capacity and can be stopped. -Learn more about [how autostop/autostart works](/reference/fly-proxy-autostop-autostart) and [how to configure it](/apps/autostop-autostart). +Learn more about [how autostop/autostart works](/reference/fly-proxy-autostop-autostart) and [how to configure it](/launch/autostop-autostart). ## Dynamic request routing with `fly-replay` diff --git a/volumes/volume-manage.mdx b/volumes/volume-manage.mdx index db136ccca8..34f73c4aeb 100644 --- a/volumes/volume-manage.mdx +++ b/volumes/volume-manage.mdx @@ -51,7 +51,7 @@ You can also configure a volume to extend automatically after a certain threshol 1. Extend the volume size: ```bash - `fly volumes extend -s ` + fly volumes extend -s ``` 1. (Optional) Check the new volume size in the Machine's file system: @@ -108,7 +108,7 @@ Create an exact copy of a volume, including its data. By default, we place the n 3. (Optional) Use [`fly scale count`](/launch/scale-count#scale-an-app-with-volumes) to create a new Machine that picks up the unattached volume, or attach the volume to a new Machine by cloning with the following command: ```bash -`fly machine clone --region --attach-volume :` +fly machine clone --region --attach-volume : ``` For options, refer to the [`fly volumes fork` docs](/flyctl/cmd/fly_volumes_fork) or run `fly volumes fork --help`. @@ -202,7 +202,7 @@ For options, refer to the [`fly volumes destroy` docs](/flyctl/cmd/fly_volumes_d **Volumes attached to Machines** -Volumes attached to Machines can’t be destroyed. You can check which Machine (if any) a volume is attached to by running `fly volumes list` First, stop and destroy the Machine, then the unattached volume can be destroyed. +Volumes attached to Machines can’t be destroyed. You can check which Machine (if any) a volume is attached to by running `fly volumes list`. First, stop and destroy the Machine, then the unattached volume can be destroyed. If you’re replacing the Machine, use `fly scale count` or `fly machine clone` to launch a new one. This will create and mount a fresh volume based on your `fly.toml` config.