Self-hosted runner with github runner as backup (when offline)

Hello everyone!

I would like to know if it’s possible to have a self-hosted runner for a private repo that falls back to a normal github runner whenever the self-hosted runner is offline.

In my particular case, since I’m maintaining a private repo for a project where me and other collaborators write documents using LaTeX, I need to use a github action that uses a Latex Docker Image, which takes about 4-5 minutes to complete, and about 3 minutes just for setting up the actions everytime.

Testing a self-hosted runner capable of caching the actions, it takes less than 2 minutes to complete everything (setup, compile, etc.). Obviously, the problem occurs when (for any reasons) the self-hosted runner goes offline, and the pull_request checks are queued, causing the workflow to hold on for too much time.

So, is there a way to configure the YAML file in order to mainly use the self-hosted runner, and, in case, the github runner as backup?


This is not something we currently support.  I have added to our feedback queue to consider for a future update.


This would be immensely helpful for open-source projects, where self-hosted runners might help to add some execution speed and higher levels of parallelism, but you’d also want to have people who fork the repository be able to get the same CI tests run for their own branches without lots of setup overhead.


I just want to bump this and say that I second/third this opinion.

We could keep a $1000 EC2 instance running through the day, but we could shut it down at night.
We need many many more cores for parallel PHPUnit, and it takes around ~10 min currently on hosted Github runners.

On such an AWS instance we can get it down to 1-2 minutes easily. It makes a big difference.

But we could also save ~1/2 the cost by shutting it down on a schedule, and having a “fallback” would also provide us the ability to have it work without modifying Github workflows, if that instance is down for maintenance or whatever.

It could even be extended to “Is there available runners? Nope, go for Github”.

I think implementing the “runs on tag” as

runs-on: [self-hosted, ubuntu-latest]

Would work. I think that might be used for tags, but then make it a runs-on-priorties tag, or imlement it as a list / array of arrays.

runs-on: [[self-hosted], [ubuntu-latest]]


    - [self-hosted]
    - [ubuntu-latest]

I think especially the array approach could be “fine”, as it could attempt the normal logic you are doing, fail within a timeout / on error, and then attempt the next “runs-on”.


We are running our dedicated runner, and it would be nice to have a fallback option when our main runner goes down, or it’s full.
I think this is a critical feature for many GitHub Actions users.


I am quite surprised, that this is not supported by the GitHub. This would be super useful.


This would be a really helpful feature.

Just want to add this would be incredibly useful in reverse as well, specifying a backup self-hosted runner in the case that there is a hosted runner outage (like right now).

1 Like

Can we get some input from someone on the github side on if this will be considered at all?

I found that in some cases if I add the custom label ubuntu-latest to my self-hosted runner then it will use the self hosted runner for actions that have runs-on: [ubuntu-latest]. I believe the order that it checks is repository runners, then organisation runners, then GitHub runner.

This may not work for all but in simple cases might do the trick.


I vote also for this one.