Fix the rendering and link problems from the meta description review

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
+<CodeGroup>
+```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
-<CodeGroup>
 ```
+</CodeGroup>
 
 `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   
+<CodeGroup>
+```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)
-<CodeGroup>
 ```
+</CodeGroup>
 
 You can also confirm that an individual Machine's config matches this, using `fly machine status <machine ID>`:
 

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.
 

networking/request-headers.mdx

@@ -6,7 +6,7 @@ source_url: https://fly.io/docs/networking/request-headers/
 
   <img src="/images/request-headers.png" alt="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
 

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
 

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`
 

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 <volume id> -s <new size in GB>`
+    fly volumes extend <volume id> -s <new size in GB>
     ```
 
 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 <machine id> --region <region code> --attach-volume <volume id>:<destination mount path>`
+fly machine clone <machine id> --region <region code> --attach-volume <volume id>:<destination mount path>
 ```
 
 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.