Update job queue assignment details for larger runners (#56988)

Co-authored-by: Larissa Fortuna <[email protected]>
Co-authored-by: Sarita Iyer <[email protected]>
Co-authored-by: Copilot <[email protected]>

Author: 4 people

data/reusables/actions/larger-runners-troubleshooting-linux-windows.md

@@ -5,4 +5,4 @@ If you notice the jobs that target your {% data variables.actions.hosted_runner
 * **Billing information:** You must have a valid credit card on file in order to use {% data variables.actions.hosted_runner %}s. After adding a credit card to your account, it can take up to 10 minutes to enable the use of your {% data variables.actions.hosted_runner %}s. For more information, see [AUTOTITLE](/billing/managing-your-billing/managing-your-payment-and-billing-information).
 * **Spending limit:** Your {% data variables.product.prodname_actions %} spending limit must be set to a value greater than zero. For more information, see [AUTOTITLE](/billing/managing-billing-for-github-actions/managing-your-spending-limit-for-github-actions).
 * **Fair use policy:** {% data variables.product.company_short %} has a fair use policy that begins to throttle jobs based on several factors, such as how many jobs you are running or how many jobs are running across the entirety of {% data variables.product.prodname_actions %}.
-* **Job queue to assign time:** Job queue to assign time refers to the time between a job request and {% data variables.product.company_short %} assigning a VM to execute the job. Standard {% data variables.product.company_short %}-hosted runners utilizing prescribed YAML workflow labels (such as `ubuntu-latest`) are always in a "warm" state. With larger runners, a warm machine may not be ready to pick up a job on first request as the pools for these machines are smaller. As a result, {% data variables.product.company_short %} may need to create a new VM, which increases the queue to assign time. Once a runner is in use, VMs are readily for subsequent workflow runs, reducing the queue to assign time for future workflow runs over the next 24 hours.
+* **Job queue to assign time:** Job queue to assign time refers to the time between a job request and {% data variables.product.company_short %} assigning a VM to execute the job. Standard {% data variables.product.company_short %}-hosted runners utilizing prescribed YAML workflow labels (such as `ubuntu-latest`) are always in a "warm" state. With larger runners, a warm VM may not be ready to pick up a job on first request as the pools for these machines are smaller. As a result, {% data variables.product.company_short %} may need to create a new VM, which increases the queue to assign time. Once a runner is in use, VMs are ready for subsequent workflow runs within 5 minutes. If not used again within that time, a subset of those machines remains warm, reducing the queue to assign time for future workflow runs over the next 24 hours. The higher the volume of jobs you run, the more VMs will remain in the warm pool.