Github private self-hosted Private runners went to offline . They are created while Azure Acclerator with terraform deployed by MS Team

Question

Github private self-hosted Private runners went to offline . They are created while Azure Acclerator with terraform deployed by MS Team

Satish B 210

Hi Team

We have observed that the GitHub self-hosted private runners are currently showing as Offline.

These runners were provisioned as part of the Azure Accelerator deployment using Terraform, and the initial setup was performed by the Microsoft team through a bootstrap script. However, the bootstrap/configuration script used during deployment was not shared

Can some one please suggest how to fix this issue.

Gursimran Singh 495 Reputation points Microsoft External Staff Moderator

2026-08-10T23:33:03.27+00:00
Hi @Satish B ,

Confirm the VM/VMSS is running. If autoscale min instance count = 0, runners scaling to zero is expected behavior, not a fault — check Azure Activity Log for stop/deallocate/reimage events around the time this started.

Check the runner service on the box:

bash

The _diag/Runner_* log in the runner install folder will usually state the exact failure (auth, network timeout, etc.).

Registration credential expiry — most common cause. If a static PAT was used for re-registration on VM recreation, check if it's expired. If it was a one-time registration token, any new VM instance created by Terraform needs a fresh one. Recommend moving to a GitHub App token instead of a PAT going forward — it doesn't silently expire the same way.

Network/firewall. Validate outbound access to github.com, api.github.com, *.actions.githubusercontent.com, codeload.github.com:

bash

Recover the missing bootstrap script yourself — you don't need MS to resend it. It's embedded in the deployment: check the VM/VMSS Custom Script Extension or Custom Data in the Azure Portal, or search the Terraform repo for the cloud-init/azurerm_virtual_machine_extension resource. Boot diagnostics → Serial log shows the original bootstrap execution output too.

Manual fix on the VM:

bash

Get tokens via GitHub → Settings → Actions → Runners → New self-hosted runner, or the API.

1 answer

Your answer

Gursimran Singh 495 Reputation points Microsoft External Staff Moderator

2026-08-10T23:33:03.27+00:00

Hi @Satish B ,

Confirm the VM/VMSS is running. If autoscale min instance count = 0, runners scaling to zero is expected behavior, not a fault — check Azure Activity Log for stop/deallocate/reimage events around the time this started.

Check the runner service on the box:

bash

The _diag/Runner_* log in the runner install folder will usually state the exact failure (auth, network timeout, etc.).

Registration credential expiry — most common cause. If a static PAT was used for re-registration on VM recreation, check if it's expired. If it was a one-time registration token, any new VM instance created by Terraform needs a fresh one. Recommend moving to a GitHub App token instead of a PAT going forward — it doesn't silently expire the same way.

Network/firewall. Validate outbound access to github.com, api.github.com, *.actions.githubusercontent.com, codeload.github.com:

bash

Recover the missing bootstrap script yourself — you don't need MS to resend it. It's embedded in the deployment: check the VM/VMSS Custom Script Extension or Custom Data in the Azure Portal, or search the Terraform repo for the cloud-init/azurerm_virtual_machine_extension resource. Boot diagnostics → Serial log shows the original bootstrap execution output too.

Manual fix on the VM:

bash

Get tokens via GitHub → Settings → Actions → Runners → New self-hosted runner, or the API.

Answer 1

Hello @Satish B

Based on your description, it sounds like the GitHub self-hosted runners were successfully registered during the initial deployment, but are no longer able to reconnect to GitHub. Since the bootstrap/configuration script isn't available, the first step is to determine whether the issue is with the runner service, authentication, or network connectivity.

I'd recommend checking the following on one of the runner VMs:

1. Runner service status

Verify that the GitHub Actions runner service is running.

Windows: Get-Service actions
Linux: sudo systemctl status actions.runner.*

2. Runner diagnostic logs

Review the runner _diag logs for authentication or connectivity errors.
Common messages include expired registration tokens, TLS failures, or inability to reach GitHub.

3. Network connectivity

Confirm the runner can reach the required GitHub endpoints over HTTPS (TCP 443), including:
- github.com
- api.github.com
- *.actions.githubusercontent.com
- If the runners are deployed in a private network, verify that the firewall, proxy, Azure Firewall, or NSGs aren't blocking outbound access.

4. Registration

If the VM was recreated or the runner configuration was lost, the runner may need to be re-registered using a new registration token from the GitHub repository or organization.

Since you mentioned these runners were created by the Azure Accelerator deployment, another important question is:

Which Azure Accelerator was used? (for example, Azure Landing Zone Accelerator, Azure AI Accelerator, Enterprise-Scale Landing Zone, etc.)
Is the runner VM still present and healthy, or was it recently recreated, updated, or scaled?

If the deployment was fully automated with Terraform, it's also worth checking whether the bootstrap extension (Custom Script Extension, cloud-init, or VM extension) completed successfully and whether the runner configuration persists after a reboot.

If you can share:

whether the runners are Windows or Linux,
the runner logs (_diag),
and whether the runner shows Offline immediately after a reboot or after some time,

we can help narrow down whether the issue is related to the runner service, registration, or outbound connectivity.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Allan Solomon Mejia 3,510 Reputation points

2026-08-11T00:56:35.4+00:00

Hi @Satish B

Please let me know if you need any further assistance. Otherwise, if the information provided has resolved your issue, please consider clicking “Accept Answer” to help others who may encounter the same problem.

Thank you!