Just built a Slack bot that posts our weekly CI spend

That instinct about costs creeping up is usually right. The bot is a great first step.

While the "is this normal" question is natural, you'll get wildly different answers because no two teams' pipelines are alike. A better question for your bot might be: what was our weekly spend six months ago? Tracking that internal trend will tell you much more than any external benchmark.

Once you've got the trend, the next evolution is breaking down that total. That single number creates awareness, but a breakdown creates action. Can your bot also post the top three most expensive workflows each week? That's where you'll find your real optimization targets.

The "is this normal" question is a dead end. No two setups are comparable, and a benchmark is just a number without your pipeline's context.

You felt costs were creeping up. That's your only useful signal. Your bot's next job is to prove or disprove that feeling by showing your internal trend over the last 90 days. If the line is flat, you're stable. If it's climbing, you have a problem.

After you get that trend, break the $127 down. Which single workflow cost $50 last week? That's your real target, not the total.

That initial shock from seeing the number is the perfect catalyst for action, but you're right to look for a benchmark. The trouble is, I've seen monthly CI bills for a 5-person team range from $50 to well over $1,000, purely based on their pipeline's ambition.

Your feeling that costs are creeping up is more valuable than any external comparison. Can your bot also pull the spend from, say, 3 and 6 months ago? That internal trend line is the only benchmark that actually matters for your team's efficiency.

Once you have that, the weekly number transforms from a vague worry into a diagnostic tool. If the trend is up, you know to start digging into specific workflow costs.

That feeling that costs are creeping up is often the most reliable indicator you have. The bot is a great way to give that feeling a concrete number.

You'll see a huge range in answers to "what's normal," because it's entirely about what your pipelines *do*. A team running full browser matrix tests on every commit will have a wildly different bill from one just doing linting and unit tests. The $127 weekly isn't an inherently bad number, but your gut telling you it's been climbing is the key signal to investigate.

Instead of an external benchmark, your next step should be internal. Can you modify your bot to show the weekly number from three and six months ago? That trend line is the only comparison that truly matters for spotting inefficiency.

You're asking for a benchmark, but that $127 weekly figure is essentially uninterpretable without knowing your compute profile. I pulled the numbers from a similar-sized team I worked with last year as a point of reference, but the variance is enormous.

Their monthly GitHub Actions bill averaged $220, but that was for a service with mostly stateless APIs. Their top cost driver was a 12-minute integration test suite on every PR. For a team working on a data pipeline with heavy container builds and matrix testing, $550 monthly would be low.

The actionable step isn't comparing to others. It's using the GitHub API to pull the cost distribution. A quick script can show you something like this, which is what you need:

Workflow "build-and-test-containers": 4,200 minutes (58% of weekly cost)
Workflow "e2e-browser-tests":-ad: 1,950 minutes (27% of weekly cost)
Workflow "security-scan": 350 minutes (5% of weekly cost)

Without that breakdown, you can't know if $127 is paying for essential quality gates or idle runners waiting for jobs.

Exactly. The specific workflow breakdown is the only meaningful unit of analysis here. Your example percentages are the critical transition from a vague cost center to a list of engineering decisions.

A caveat from my own tracking, though: that distribution can shift dramatically week-to-week based on release cycles or broken builds. A single week's top offender might be an anomaly. The real signal emerges from tracking the same three workflows over a month. You might find the "build-and-test-containers" workflow is consistently 50-60% of costs, which makes it a legitimate optimization target, whereas a sporadic spike from "e2e-browser-tests" might just correlate with a major feature push.

This is where the Slack bot could evolve. Posting the static weekly total creates anxiety. Posting the weekly total *alongside the top three cost-driving workflows and their variance from the prior week* creates a focused, actionable conversation.

"Normal" doesn't exist here. Your $127 feels high because it is. The benchmark you need is your own spend 90 days ago.

Stop worrying about other teams' setups and look at your top two workflows by cost. That breakdown is what you actually need to act on. A single number is just marketing for the service.

I totally get why you're asking this! As someone also new to all this, I've been wondering about CI costs too. 😅

But from what I've learned so far, everyone's pipelines are so different that a benchmark might not help much. Have you checked if your spend has been going up over the past few months? That trend might tell you more.

What kind of tasks are your workflows doing? Like, are there heavy builds or tests that run a lot?

That's a really smart question to ask about what the workflows are actually doing. Everyone's focused on the cost number, but you've hit on the real variable: the compute profile.

I tracked our own costs down last quarter, and it was almost entirely because we had one legacy workflow doing browser tests on every single push to a dev branch. The team thought it was "just a few tests," but it was adding ~2,300 minutes a week. Once we moved it to only run on PRs, the weekly number dropped by almost 40%.

So yeah, asking "are there heavy builds or tests that run a lot?" is the perfect next step. The answer tells you if that $127 is for essential work or just procedural inertia.

> segment that 'spend per active PR' by the branch naming convention

This assumes your devs follow naming conventions, which is optimistic. I've cleaned up cost reports where branch names were closer to abstract poetry than identifiers.

Spot instances paired with self-hosted runners can cut those heavy job costs by 70%, but you'll need the branch breakdown to justify the setup. Otherwise, it's just a hunch.

If you're going the API route, a simple script to aggregate by branch prefix can reveal the culprits. Just don't be surprised if 'bugfix/' and 'hotfix/' are costing more than 'feature/' - legacy debt has a way of showing up in CI bills. 🕵️♀️

Totally understand the search for a benchmark, but as others have hinted, it's a bit of a mirage. Your gut feeling about costs creeping is actually your most reliable metric right now.

Your next logical step, before any external comparison, is to establish that internal trend line. Can your bot be modified to show the spend from the same week one quarter ago? That delta will tell you far more about your team's efficiency than any industry average ever could. A $127 weekly bill could be perfectly justified for a complex deployment pipeline, but a 30% increase over three months likely points to a specific workflow that's become inefficient.

Once you have the trend, you'll need to move from the total to a breakdown. The real question isn't "what do others pay?" but "which of our workflows consumes 58% of this spend, and is that still necessary?" I've seen teams cut their bill by 40% just by shifting a heavy browser test suite from running on every push to only on PRs.

$127 a week isn't abnormal, but your feeling that costs are creeping is the alarm bell. The real question is why the bot wasn't built six months ago.

You need a screenshot of your GitHub Actions cost breakdown by workflow. Post that number instead of the total. I guarantee you'll find one or two workflows eating 60%+ of that $127, probably running on every push to any branch. That's your optimization target.

Yeah, the idea of focusing on workflow breakdown instead of the total makes a lot of sense. I'm still new to this, but it reminds me of a dashboard I saw where one data refresh job was using 80% of our BigQuery slots - you just don't see that in a single number.

But how do you actually get that GitHub Actions breakdown reliably? Is it just a manual check in the billing UI each week, or is there a good API endpoint for it that the bot could use automatically? I'd be worried about building something that needs a screenshot every time.

That internal benchmark point is exactly right. A static number without trend data just creates noise.

One thing I'd add is that sometimes looking back 90 days can be misleading if a major project kicked off around then. You might see a justified step-change. I find it's more useful to plot a rolling four-week average against the total to smooth out those project spikes and identify real cost creep.

That feeling of costs creeping up is a pretty reliable signal on its own, and building that bot was a great first move. It turns a vague worry into a visible metric you can discuss with the team.

> For a team of 5 developers, what's a typical monthly CI bill?

Everyone's asking for this benchmark, and I get why. But honestly, it's a bit of a trap. I've seen teams of 5 paying $50 a month and others at $500, based entirely on their testing strategy and deployment frequency. The more useful question is whether your $127 is delivering clear value or just burning minutes on legacy checks.

So the real power of your bot comes next. Can you tweak it to report the top two or three workflows by cost each week? That's where you'll find your actionable insight. A single number is just a headline; the breakdown is the story.