GitHub Actions self-hosted runner on Azure Windows VM intermittently stops picking up queued jobs until service restart

Question

GitHub Actions self-hosted runner on Azure Windows VM intermittently stops picking up queued jobs until service restart

Jonathan Everald Panenga Putra 0

Hi,

We are running a GitHub Actions self-hosted runner on an Azure Windows VM for Playwright automation testing.

The GitHub Actions runner is installed as a Windows service so that it remains available in the background.

Environment

Azure Virtual Machine

Windows OS

GitHub Actions self-hosted runner

Runner installed as a Windows service

Runner labels: self-hosted, windows, x64

Main workload: Playwright browser automation tests

Problem

Intermittently, GitHub Actions jobs targeting this runner remain in the Queued state for an unusually long time.

We have observed jobs queued for:

approximately 30 minutes

several hours

up to approximately 5 hours in one case

The issue does not occur consistently.

Initially, we suspected that this might happen when someone was actively using the Azure VM.

We tested this by connecting to and using the VM while triggering the automation workflow. The runner was still able to pick up and execute the job successfully.

We also compared the automation execution time while the VM was actively being used versus when nobody was using it. There was no significant difference in execution time.

Therefore, normal interactive usage of the VM does not appear to explain the issue.

Service restart behavior

During one occurrence where a GitHub Actions job remained queued, we restarted the GitHub Actions runner Windows service.

Immediately after the service was restarted, the queued workflow was picked up and started normally.

Since restarting the service, the issue has not occurred again so far.

Current suspicion

We suspect that either:

the GitHub Actions runner service/listener occasionally becomes stuck,

the runner loses or has an unhealthy outbound connection to GitHub Actions,

or there is some Windows/Azure VM networking or service-level condition affecting the runner communication.

From GitHub documentation, the self-hosted runner initiates outbound HTTPS communication with GitHub Actions and needs that connection to receive job assignments.

Questions

From the Azure VM/Windows side:

Are there any known Azure VM networking conditions that could cause a long-running background service to temporarily lose or stall an outbound HTTPS connection while the VM itself continues operating normally?

Could Azure networking, NAT, firewall, DNS, TCP connection timeout, or VM network adapter behavior affect a long-running GitHub Actions runner connection?

Are there Azure-side logs or metrics you would recommend checking when the issue occurs?

Would Network Watcher, NSG flow logs, VM metrics, or Windows Event Viewer be useful for identifying this?

Are there recommended settings for running a GitHub Actions self-hosted runner reliably as a Windows service on an Azure VM?

The problem is currently not reproducible. If it happens again, we plan to collect the GitHub runner diagnostic logs before restarting the service.

We would also like to know which Azure VM/network diagnostics should be collected at the same time so we can determine whether this is a GitHub runner issue or an Azure/Windows connectivity issue.

VarunTha 15,090 Reputation points Microsoft External Staff Moderator

2026-09-10T20:43:37.09+00:00

Additional to Salamat Shah:

Before restarting the runner service during the next occurrence, verify whether the runner is shown as Offline, Idle, or Active under GitHub Settings > Actions > Runners. If it is Offline, collect the runner _diag logs and test DNS and TCP 443 connectivity to the required GitHub endpoints from the VM.

Because the issue is intermittent, consider configuring Azure Network Watcher Connection Monitor or another continuous outbound connectivity check in advance. An on-demand connectivity test performed only after the runner service is restarted may not capture the transient condition.

Also, Windows Service Recovery actions normally trigger when a service process terminates. They may not restart a service whose process remains running but whose listener is unresponsive, so service recovery should be treated as mitigation rather than confirmation of the root cause.

1 answer

Your answer

VarunTha 15,090 Reputation points Microsoft External Staff Moderator

2026-09-10T20:43:37.09+00:00

Additional to Salamat Shah:

Before restarting the runner service during the next occurrence, verify whether the runner is shown as Offline, Idle, or Active under GitHub Settings > Actions > Runners. If it is Offline, collect the runner _diag logs and test DNS and TCP 443 connectivity to the required GitHub endpoints from the VM.

Because the issue is intermittent, consider configuring Azure Network Watcher Connection Monitor or another continuous outbound connectivity check in advance. An on-demand connectivity test performed only after the runner service is restarted may not capture the transient condition.

Also, Windows Service Recovery actions normally trigger when a service process terminates. They may not restart a service whose process remains running but whose listener is unresponsive, so service recovery should be treated as mitigation rather than confirmation of the root cause.

Answer 1

Based on the fact that restarting the runner service immediately cleared the queue, the issue is most likely related to the GitHub runner listener process or its connection to GitHub Actions, rather than Azure VM performance. Focus troubleshooting on runner logs and outbound connectivity monitoring when the issue occurs again.

Recommended Steps:

Ensure the GitHub self-hosted runner is updated to the latest version.

Configure Windows Service Recovery to automatically restart the runner service if it becomes unresponsive.

Monitor outbound HTTPS (TCP 443) connectivity to GitHub endpoints.

If the issue reoccurs, collect:

GitHub Runner diagnostic logs (_diag)

Windows Event Viewer logs

Azure Network Watcher diagnostics

NSG Flow Logs (if enabled)

VM CPU, Memory, and Network performance metrics.