Why our unattended publishing slot kept firing late

Description and use

Problem: GitHub Actions scheduled jobs drifted 55–65 minutes late due to shared queue and high load. Fix: use an external HTTP scheduler to trigger workflow_dispatch, moving the trigger outside GitHub’s queue. This reduces drift but requires token validation and monitoring of the external scheduler.

Problem

GitHub Actions scheduled jobs drifted 55–65 minutes late or failed to run, causing unattended publishing pipelines to miss their intended times.

Outcome

The external scheduler approach reduces drift by moving the trigger outside GitHub’s shared queue, but introduces its own potential failures and requires monitoring of the dispatch call.

Workflow

• 1. Keep existing schedule: cron block as a fallback. 2. Create a curl command to POST to GitHub API actions/workflows/<WORKFLOW_FILE>/dispatches with required headers and branch ref. 3. Register the same request with a free external scheduler (e.g., cron-job.org) to run at the desired time. 4. Add a monitoring step to check the HTTP status of the dispatch call and alert on failures. 5. Verify the workflow runs on time; if external scheduler fails, the GitHub cron fallback still triggers the job (though late).

Evidence

Scheduled events can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped.

Source

In GitHub's own community forum, a GitHub staff member acknowledged that scheduled-job drift has been getting worse, with the drop rate up more than 30% over two months.

Source

The fix — use an event that isn't on that queue. schedule shares a queue with every other repo's scheduled jobs. workflow_dispatch runs on a different path with no such drift.

Source