Are GitHub Actions runners slow or failing lately?

Check GitHub's service status first. The discussion pointed to an Actions incident involving longer queue times, so a job waiting for a runner isn't necessarily a problem with your workflow.

If the status page is clear, check the job's runs-on label against the supported runner labels and look at whether it fails before starting or during a step. Those are different problems.

Self-hosted runners give you more control over the machines, but they don't remove GitHub from the workflow. If GitHub isn't responding or scheduling jobs properly, those runners can be affected too.

Before moving everything, separate runner availability problems from issues with the service that dispatches the jobs. Self-hosting only directly addresses the first part.

The AI build load explanation is speculation. The reported queue incident supports the idea that Actions was having trouble, but it doesn't establish what caused it or whether AI-generated builds were involved.

There's also a bigger question here than this particular outage. Some people find Actions awkward for organizing workflows, managing secrets, or separating environments and would rather move to another CI system.

Others prefer Actions to Jenkins and see them as different tools rather than direct substitutes. If you're considering a move, compare how each one handles the workflows you actually need instead of assuming self-hosted runners will fix every frustration.

For scheduled workflows specifically, the scheduler can be another point of failure. One alternative discussed was using Kubernetes cron jobs to call the GitHub API, though that adds another system to operate and doesn't eliminate dependence on the API responding.