Schedule-triggered workflow runs consistently delayed 2-3 hours with a self-hosted runner (workflow_dispatch runs fine)

[kariscodes]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Summary

All four schedule cron triggers in my workflow have started 2-3+ hours
later than their configured time, reproduced identically on two
consecutive weekdays. workflow_dispatch (manual) runs on the same
self-hosted runner always start within seconds, so this appears specific
to schedule events rather than the runner itself.

Setup

• Runner: self-hosted, Linux x64, single runner, always online
• Workflow file: .github/workflows/scheduled_run.yml
• runs-on: [self-hosted, Linux]

Schedule (verified correct — KST to UTC conversion double-checked)

schedule:
  - cron: "30 0 * * 1-5"   # intended 00:30 UTC
  - cron: "30 3 * * 1-5"   # intended 03:30 UTC
  - cron: "30 5 * * 1-5"   # intended 05:30 UTC
  - cron: "50 6 * * 1-5"   # intended 06:50 UTC

Observed actual start times (from the runner's own Runner_*.log,
"Running job" entries — timezone UTC)

Date | Intended | Actual | Delay
2026-07-15 | 00:30 | 03:44:27 | ~3h14m
2026-07-15 | 03:30 | 05:45:01 | ~2h15m
2026-07-15 | 05:30 | 07:29:13 | ~1h59m
2026-07-15 | 06:50 | 09:02:15 | ~2h12m
2026-07-16 | 00:30 | 03:46:45 | ~3h17m
2026-07-16 | 03:30 | 05:58:15 | ~2h28m
2026-07-16 | 05:30 | 07:35:58 | ~2h6m
2026-07-16 | 06:50 | 09:05:40 | ~2h16m

Runner-side evidence

The runner's diagnostic log shows continuous "Listening for Jobs" with no
disconnects during the delay windows, so the runner was not the
bottleneck. Interestingly, both days show a
Received RunnerRefreshConfigMessage for 'runner' config file event at
almost the same time each day (~02:48-02:50 UTC), and the first delayed
job of the day is only dispatched roughly 50-60 minutes after that
event — well after the intended 00:30 UTC trigger.

Question

Is this expected/known behavior for schedule-triggered workflows
dispatched to self-hosted runners? Is there a known relationship between
the daily RunnerRefreshConfigMessage timing and delayed job dispatch?
Happy to share the full runner diagnostic logs if that's useful for
investigation.

[jasonmiller2332]

This looks more like a GitHub Actions scheduling delay than a self-hosted runner issue. Since manual runs start immediately and the runner stayed online, I'd focus on the dispatch side rather than the runner. I wouldn't assume the RunnerRefreshConfigMessage is related—it normally occurs as part of routine runner maintenance. If the delays continue, I'd open a GitHub Support ticket with your logs and timestamps, as they should be able to verify when the schedule event was actually generated and dispatched.

[xusnitdinov]

What you are seeing is consistent with GitHub's documented behavior for schedule, and it points more to dispatch timing than to the self-hosted runner itself.

GitHub's docs explicitly say:

• scheduled workflows can be delayed during periods of high load
• high load includes the start of every hour
• if the load is high enough, some queued jobs may even be dropped
• scheduled workflows only run from the latest commit on the default branch

Docs:
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows

Since your manual workflow_dispatch runs start immediately and your runner logs show the runner stayed online and listening, I would not treat the runner as the primary suspect here. The RunnerRefreshConfigMessage is more likely normal runner maintenance noise than the cause of the delay.

The main things I would still verify are:

1. the workflow file with the schedule: block is definitely on the default branch
2. the workflow is not disabled
3. avoid top-of-hour schedules when possible

Your current minutes are :30 and :50, which is already better than :00, so if you are still consistently seeing 2 to 3 hour delays across multiple days, I would escalate this to GitHub Support with:

• the workflow YAML
• repo URL
• exact intended vs actual UTC times
• runner diagnostic logs
• confirmation that manual runs start immediately

That should help them determine whether the delay is happening before dispatch or after dispatch.