GitHub Actions Was Burning Through My Allowance Faster Than Expected. Here’s What I Stopped Automating.

I used to think more automation automatically meant more efficiency.

For my browser game, code changes could trigger deployment, browser checks, and automated screenshots for social media. It felt elegant—until I looked at the usage.

The automation was consuming my GitHub Actions allowance much faster than I expected.

GitHub Actions is not unlimited free compute

Actions can run tests, deployments, scheduled jobs and browser automation on hosted runners. Those runners have different costs.

macOS can cost far more than Linux

As of October 2026, GitHub’s standard hosted-runner overage pricing lists Linux (2-core) at $0.006/min, Windows (2-core) at $0.010/min, and macOS (3–4 core) at $0.062/min.

That makes macOS roughly 10.3× the Linux rate.

A single screenshot could take minutes

My automated screenshot flow launched a browser, opened the game, navigated to a scene and captured the screen. One run could take 8–9 minutes.

Repeat that for layout tweaks, retries and mobile checks, and minutes pile up fast.

Automatic production deploys added more unnecessary runs

A one-line dialogue fix can still trigger the whole deployment pipeline. The amount of code changed does not necessarily match the amount of automation time consumed.

So I reduced automation

I stopped automatic screenshot generation and changed production deployment so it no longer runs on every push. Instead, I batch changes and run the production deploy manually when I actually want to publish.

GitHub Actions supports this with workflow_dispatch.

I did not stop using GitHub Actions. I changed when it runs.

Do not cut the safety checks that matter

Cost savings should not mean removing verification, rollback paths or checks that prevent incomplete files from reaching production.

I previously documented a case where my game worked on my own PC but failed on phones: My Web Game Worked on My PC but Broke on Phones — The Deployment Trap I Missed.

What I now check before adding automation

Which runner does it use? What event triggers it? How often does it run? How long does each run take? Could it run on Linux? Can it be manual instead of automatic? Is there a budget alert?

More automation is not always more efficient

Automation still needs maintenance, debugging and compute. Worse, once a workflow exists, it is easy to stop asking whether it is still useful.

AI makes automation easier—and makes restraint more important

AI can build sophisticated workflows quickly. But cheap creation does not mean cheap operation.

The important skill is not only knowing what to automate, but also what to stop automating.

I wanted to build a game, not an automation system

My goal is to create characters, scenes and a story people want to continue—not to maximize the number of workflows I maintain.

Now I run what I need, when I need it, while keeping the safety checks that matter.

Play the free ORA Quest Sin demo

コメント