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
- macOS can cost far more than Linux
- A single screenshot could take minutes
- Automatic production deploys added more unnecessary runs
- So I reduced automation
- Do not cut the safety checks that matter
- What I now check before adding automation
- More automation is not always more efficient
- AI makes automation easier—and makes restraint more important
- I wanted to build a game, not an automation system
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.

コメント