What running TrimCI actually looks like

Fieldnote Labs builds a logistics SaaS: fourteen engineers, twelve active repositories, a heavyweight integration suite and nightly e2e pipelines. CI is owned by Marta, a staff engineer, because she broke it last. A release just slipped two days — a nightly pipeline had been silently red since the previous Thursday, and "re-run until green" is muscle memory nobody logs. She knows CI is bad; she cannot say which pipeline to fix first or what the waste costs.

She creates a TrimCI organization (14-day Business-equivalent trial, no credit card), installs the GitHub App — Actions and Metadata read-only, never repository contents — and ticks all twelve repos for the 60-day backfill. In org settings she sets a $75 fully-loaded hourly rate and two SLO targets; on the billing card she excludes one drive-by external contributor.

The estimated-loss card reads ≈$10,200 for the 30-day window — modelled as 40 engineer-minutes per failure at her rate plus a 15% rework tax, an estimate, not payroll. The report turns that into a fix list: the cost Pareto shows two pipelines carrying 71% of cumulative failure cost, the flaky-pipelines section flags the integration suite at a 44% flip ratio, retry tax counts 18% of runs retried (≈1,900 wasted minutes), and error fingerprints cluster the failed-log tails into named problems. MTTR puts the nightly's median recovery at 52 hours — and the "silent red nightlies" callout names it explicitly.

Marta quarantines the flaky tests, the team fixes the test-container issue the fingerprints pointed at, and nightly ownership joins the on-call rotation — TrimCI never touched the pipeline; it ranked the fire. Six weeks later the movers section documents the worst repo's failure rate falling from 22% to 9% over decisive runs, and estimated loss drops by about $4,100 a month.

The monthly bill: 11 active contributors × $7 on Team = $77/month. Members who only read dashboards cost nothing.

An engineering manager at a ~90-person B2B SaaS scale-up owns three squads shipping across 24 repositories. Last quarter a sprint slipped and her honest answer upward was "CI was red half the week" — a feeling, not a number. The monthly report costs an hour of screenshot archaeology computed differently every time, failures cluster on certain repos and days but she learns that from Slack, and the cleanup work she sponsors has no before/after evidence, so in the budget deck it reads as pure cost.

She installs the GitHub App — Actions and Metadata read-only, never repository contents — and ticks her 24 repositories for the 60-day backfill. She invites her director and finance partner as members: full dashboards and reports, never billed. In org settings she sets an $85 hourly rate, a 10% failure-rate SLO target, a $9,000 monthly failure-cost budget, and a $0.008 per-runner-minute compute rate.

The 30-day window logs 1,510 decisive runs at an 11.4% failure rate, up 2.1 points vs the prior period. The estimated-loss card reads ≈$11,200 — about $320 per developer — openly a model, and the PDF's methodology appendix says so; that is the first thing her finance partner probes. The failure calendar shows a Thursday cluster, the repository breakdown pins ~40% of the loss on two services, the cost outlook's −25%-failures scenario models ≈$2,800/month of savings, and the SLO section counts 12 of 30 days in violation.

That report gets one sprint of CI cleanup approved. A month later the next report — rendered from a frozen payload, so last month's numbers never silently shift — shows four of the top-five regressing repos improved, the failure rate down from 11.4% to 8.2%, estimated loss down to ≈$8,100, and SLO violations down to 4 days. The upward report is now: click Generate, download, attach.

The monthly bill: 29 active contributors × $7 on Team = $203/month. Her director, finance partner and PMs cost nothing.

Ferrite Labs is a seed-stage devtools startup: eight engineers, nine private repositories, all-in on GitHub Actions. The CTO still merges code daily, owns the infra bill and the investor update — and nobody owns CI. The Actions invoice grew ~40% across two quarters with zero attribution, and tools demanding code access were a non-starter for private repos.

The afternoon the invoice landed he connected TrimCI: the GitHub App's read-only, zero-code-access permissions made it a two-minute security decision even on private repos. He set an hourly rate, a compute rate per runner-minute, and a failure-rate SLO target.

The 30-day baseline was uncomfortable: an 11.6% failure rate over decisive runs, ≈$4,970 of modelled failure loss against $488 of attributed compute spend, and — the real find — the trigger breakdown's "silent red nightlies" callout showing the e2e pipeline red nine straight days. On day 8 of the trial, automatic spike detection — a Business feature, active throughout the trial — fired: the 24-hour failure rate had jumped from 6% to 31% after a runner-image change, and the AI batch (self-hosted model — logs never leave TrimCI's servers) named the affected repos.

The team rolled back the runner image the same day; the catch was TrimCI's, the fix was theirs. By trial end the failure rate sat under the SLO target, and the report's executive summary became the delivery-health slide in the investor update. Post-trial the org continued on Free: nothing was deleted and every run already collected stayed put, with Free's two-repository cap applying the next time they edit the repository picker. The longer history window reopens over that same data the moment they upgrade.

What Team would cost them: 6 of the eight engineers actually trigger pipelines, so 6 × $7 = $42/month. Bots are excluded automatically.

A Stuttgart company builds industrial control software: 60 engineers, 14 repositories, all CI on a self-hosted GitLab CE 16 instance with a company-owned runner fleet. Roughly 3,000 pipeline runs a month and nobody can say what failures cost; developers complain "CI is slow" but queue time and execution time are inseparable without ad-hoc scripts. Two CI-observability SaaS candidates already failed security review — one demanded repository read scope, the other ships logs to a US cloud and OpenAI.

Signup auto-applies the DPA with 30-day sub-processor notice, and the published sub-processor list has exactly two entries: Hetzner (EU hosting) and Brevo (email). The platform lead pastes a read_api group token — self-hosted GitLab 14+ works on every plan, no app registration on her side — and the decisive point for the security reviewer is enforced in code: a runtime allowlist rejects any request outside pipeline endpoints before it leaves the process, so repository contents are never requested. Job-log excerpts are the one thing that does reach TrimCI, and they carry whatever the build printed. Tokens are encrypted at rest and expiry warnings arrive 7 days and 1 day ahead. She invites the DPO and the engineering director as members — dashboard-only viewers, never billed.

The 30-day window shows 3,050 runs, a 14.0% failure rate over decisive runs, and ≈$13,800 of modelled loss at her $45 rate. The first PDF delivers what she never had: queue time at p50 2m 40s but p95 14m 10s — the signature of peak-hour runner saturation — plus 41 red hours on main, a 5.1-hour median MTTR, and error fingerprints clustering disk-space and timeout classes — log excerpts she traced back to two overloaded runners herself. AI recommendations run on TrimCI's self-hosted model, secrets redacted before prompting — logs never reach OpenAI or Anthropic — so the AI feature survives DPO review instead of triggering it. The DPO clears the data flow: EU-only Hetzner hosting, failed-log tails capped at 8,000 characters and auto-deleted after 30 days.

The queue-time p95 turns a hunch into a budget case: two additional runners approved within a week. The follow-up report shows queue p95 at 2m 38s, red-main hours down from 41 to 19, the failure rate at 11.6%, and median MTTR at 2.9 hours. The quarterly-review spreadsheet is retired — she generates the PDF on demand before each review.

The monthly bill: 47 active contributors × $16 on Business (60-day window, hourly sync, unlimited reports) = $752/month. The DPO and the director view for free.

A 25-developer software house in Gdańsk runs four concurrent client engagements. At renewal time its most demanding client asked "is my project actually healthy?" — and the delivery director answered with a self-graded Jira screenshot. She cannot grant repo access: her IP and her other clients' IP forbid it. Meanwhile a fixed-price project was quietly rotting, its rerun-and-debug hours eating margin with no line item in any profitability review to catch it.

She creates one TrimCI organization per engagement — four orgs, switched from the sidebar, isolation validated on every request. The GitHub App covers two engagements, gitlab.com OAuth the third, and a read_api PAT the fourth client's self-hosted GitLab CE. The renewal-risk org gets the engagement's $95 blended bill rate and a 10% failure-rate SLO target; the fixed-price org gets its $80 internal cost rate. She invites the difficult client's PM as a member — free, because dashboard-only members are never billed.

The fixed-price org is the shock: a 28% failure rate over ~620 decisive runs, an estimated ≈$10,700 of modelled loss for the 30-day window. Error fingerprints cluster the redacted failed-log tails into three recurring error classes, the flaky-pipelines section flags two pipelines flip-flopping across their last 10 decisive runs, and branch health counts the hours main sat red. Before each steering call she generates the PDF for the renewal client — and the client's PM logs into the same dashboard herself.

Two sprints later — flaky pipelines stabilised, top fingerprint classes worked through — the org's failure rate is down to 11%, and the movers section documents the recovery in the next PDF. Estimated monthly loss falls from ≈$10,700 to ≈$4,000: a model estimate built from the org-entered rate, not payroll fact, but finally a CI-waste line in the quarterly profitability review. The renewal client signed, citing the monthly report.

The monthly bill: three separate Team subscriptions, 15 pipeline-triggering developers in total × $7 = $105/month across the engagements, each passed through on its client's invoice. Contributors are counted per organization, so a developer active in two engagements is billed in both. A dormant maintenance engagement stays Free; every client PM: $0.

Elena leads seed investments at a small EU fund. Her portfolio company — three employees, none technical — outsources all development to a 12-person software agency contracted for five FTE. She has a $250k milestone tranche to release, and her only progress signal is the agency's own status slide. The agency refuses repo access, reasonably: their IP, other clients' code. She could not read code anyway.

TrimCI dissolves the stand-off because it never requests repository contents: the agency connects the GitHub App (Actions and Metadata read-only — a runtime allowlist blocks anything else in code) and invites Elena as a member. Her own login, read-only, free on every plan — dashboard-only members are never billed.

Her weekly pulse is the Total Runs card: ~500 runs in the 30-day window, a daily sparkline with no dead weeks — pipeline runs are hard-to-fake exhaust of real development. The failure calendar shows weekday clustering consistent with steady work. Before each steering call she generates the PDF report herself; on the call, the agency walks her through the billable-contributors view: four distinct humans triggered pipelines in the last 30 days against five contracted FTE — a factual conversation starter, not a verdict. (The fifth is a designer who rarely touches CI. Runs prove activity, not hours — this is delivery observability, not time tracking.)

The tranche was released on evidence plus slides, not slides alone. Six weeks and two steering calls later, the failure rate is under the agreed target and MTTR fell from 5.1 to 3.2 hours — and Elena arrives at steering calls with informed questions instead of hopeful ones.

The monthly bill — paid by the agency, not the investor: 4 active contributors × $7 on Team = $28/month. Elena's seat: $0.

Dana is the BizOps analyst who owns tooling spend at a 90-person logistics-software company — 55 engineers pushing several thousand workflow runs a month across a monorepo and ~19 service repos she has zero access to, because security policy forbids repo access for non-engineers. Every quarter "what does CI actually cost us?" gets a shrug, or a borrowed engineer, a week, and a spreadsheet computed differently than last time. CI waste sits invisibly between payroll and the cloud bill: it appears in neither.

The VP of Engineering does the setup; Dana never touches a provider. He installs the GitHub App — Actions and Metadata read-only, never repository contents, so security signs off — ticks the 20 repositories, and invites Dana as a member: full dashboard and report read access, zero provider permissions, her seat free. In org settings he sets an $80 fully-loaded hourly rate, a $0.008 per-runner-minute compute rate, and a $10,000 monthly failure-cost budget SLO.

On the 30-day window the estimated-loss card reads ≈$9,400 — about $172 per developer — split into engineer-hours, debug labor, and the 15% rework tax. Dana generates the PDF herself (any member can). Inside: the hard compute-cost block attributes ≈$1,800 of runner spend, the cost Pareto shows three repos driving 64% of failure cost, and the methodology appendix states every formula — so next quarter's number is computed identically.

The quarterly review gets its first CI line items: ≈$9,400/month of modelled labor waste plus ≈$1,800 of attributed compute spend, tracked against the $10,000 budget SLO. After engineering works the "Where to start" list against the three Pareto repos, the following report shows failed runs down from 154 to 112 and modelled loss at ≈$6,900. Dana is explicit in her deck: these are model estimates on org-entered rates — numbers to argue from, not book — but it is the same model every month, and that repeatability is the win.

The monthly bill — owned by the VP of Engineering: 34 active contributors × $7 on Team = $238/month. Dana's seat and the CFO's: $0.