Skip to content
Notifications
Clear all

Check out what I made: a simple script to alert on CI cost overruns

2 Posts
2 Users
0 Reactions
2 Views
(@cost_cutter_99)
Estimable Member
Joined: 4 months ago
Posts: 124
Topic starter   [#9367]

Okay, so I was reviewing our team's monthly cloud bill and noticed a 40% spike. Traced it back to a misconfigured GitHub Actions workflow that was spinning up 4-core runners and then... just sitting there for hours on a cron job. Classic.

I realized we didn't have a simple, near-realtime guardrail for this. The billing dashboards are always a month behind, and by then the damage is done. So I threw together a script that polls the GitHub API (or GitLab, or Azure DevOps—it's adaptable) for workflow run minutes, applies the per-minute cost for your runner types, and fires off a Slack message if the daily or weekly spend crosses a threshold you set.

It's not fancy, but it works on a shoestring budget. You run it as a scheduled job itself, maybe every 6 hours. Here's the core logic:

- Fetch runs for the last period (e.g., last 24h) using the API.
- Filter for `completed` runs, sum `billable minutes` per runner size (e.g., `UBUNTU_4_CORE`).
- Apply the platform's published per-minute rates (GitHub's are public).
- Compare against your threshold. If over, format a message with the top 3 most expensive repos/workflows and post to Slack/Teams.

The key for me was building in the rate lookup, because those macOS minutes will *obliterate* your budget if a test matrix gets out of hand. I have it configured with our internal rates for private runners too.

Why not just use the built-in tools? The native insights are great for historical trends, but I wanted something proactive that could flag an anomaly *this week*, not next month. And it's maybe 150 lines of Python.

Has anyone else built something similar? I'm curious how you handle cost allocation—tagging runs by team or project is my next hurdle. The metadata just isn't there in the standard API fields.



   
Quote
(@finops_auditor_ray)
Estimable Member
Joined: 4 months ago
Posts: 115
 

That's clever for catching runner waste, but you're still trusting the platform's API to be the source of truth for cost. What if your script itself has a bug and stops firing? Or the API changes?

You need a secondary, independent verification layer. The actual cloud bill line item from AWS/GCP/Azure for the CI service is the only thing that matters. I'd run this script, but also set up a separate budget alert in the cloud provider's console for a daily spend threshold on that specific cost category. Then you have two tripwires.

Also, post a screenshot of the Slack alert next time. I wanna see the actual cost numbers it caught.


show me the bill


   
ReplyQuote