A free macOS menu bar app for self-hosted GitHub Actions runners. It asks launchd whether each runner is alive and GitHub whether it still counts on it, and never mixes up the two answers.
Hi everyone, I'm Pedro, and Standfast is my side project.
If you host a GitHub Actions runner on a Mac, you may know this one: ./svc.sh status still says Started, but GitHub has stopped sending it jobs. You find out when someone asks why a build has been queued for an hour.
Standfast checks both sides on every refresh: launchd for the process, the GitHub API for the registration. When the process is running but GitHub has the runner offline, it shows Disconnected instead of looking healthy.
It also shows how long the current job usually takes, what's queued for repository runners (with a token), and how much disk work and diag use, with a cleanup that never touches checkouts.
Free, MIT-licensed, no telemetry of its own, macOS 14 or later:
brew install --cask perafan18/tap/standfast
One question: when one runner is busy and another is disconnected, the menu bar icon shows busy, because a running build is usually what someone is waiting on. Would you rather it showed the warning first?
Checking both sides on every refresh is the key detail here. A runner that looks healthy from launchd alone can still be offline in GitHub, and that mismatch is exactly the kind of silent failure that only surfaces when a build has been queued for an hour. I also agree with surfacing the disconnected state first in the menu bar: a busy runner is working as expected, while a disconnected one is the state you actually need to act on. Keeping the cleanup away from checkouts is a reassuring constraint for a tool that runs alongside real work.
About Standfast on Product Hunt
“Know if your Mac's GitHub Actions runners will get work”
Standfast launched on Product Hunt on October 26th, 2026 and earned 74 upvotes and 5 comments, placing #24 on the daily leaderboard. A free macOS menu bar app for self-hosted GitHub Actions runners. It asks launchd whether each runner is alive and GitHub whether it still counts on it, and never mixes up the two answers.
Standfast was featured in Mac (103.8k followers), Developer Tools (521.9k followers) and GitHub (41.5k followers) on Product Hunt. Together, these topics include over 133.4k products, making this a competitive space to launch in.
Who hunted Standfast?
Standfast was hunted by Pedro Perafán Carrasco. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how Standfast stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Pedro Perafán Carrasco
Hi everyone, I'm Pedro, and Standfast is my side project.
If you host a GitHub Actions runner on a Mac, you may know this one: ./svc.sh status still says Started, but GitHub has stopped sending it jobs. You find out when someone asks why a build has been queued for an hour.
Standfast checks both sides on every refresh: launchd for the process, the GitHub API for the registration. When the process is running but GitHub has the runner offline, it shows Disconnected instead of looking healthy.
It also shows how long the current job usually takes, what's queued for repository runners (with a token), and how much disk work and diag use, with a cleanup that never touches checkouts.
Free, MIT-licensed, no telemetry of its own, macOS 14 or later:
brew install --cask perafan18/tap/standfast
One question: when one runner is busy and another is disconnected, the menu bar icon shows busy, because a running build is usually what someone is waiting on. Would you rather it showed the warning first?