CI build time monitoring with per-module regression alerts

The moment this becomes urgent is when a developer opens a PR, the CI build takes 22 minutes instead of the usual 14, and nobody knows why — or even notices, because CI time drift happens gradually and there's no baseline to compare against. By the time a team is complaining that 'gradle builds take hours,' the regression has been accumulating for weeks across dozens of incremental changes to the project structure.

The gap persists because CI vendors report total build time but don't break it down by Gradle module, task type, or configuration phase in a way that surfaces which recent code change caused the spike. The data is theoretically available in Gradle build scans, but correlating a CI time regression to a specific PR or module change requires someone to manually dig through scan comparisons — work that never gets prioritized because it's not blocking any individual ticket.

Engineering managers who care about developer productivity don't have a single number to point to that says 'build time regressed 40% in the last three weeks and it started when we added this module.' Without that, the conversation with developers stays at 'builds feel slow lately' rather than 'here's the specific change that caused it and here's what we need to revert or restructure.'

This is a business because CI time is money in two ways: direct CI compute cost (which is metered on every major CI provider) and indirect developer waiting cost. Both recur every week and both get worse as projects grow. An alert that fires when a PR causes more than a 15% build time increase — before it merges — would change developer behavior in real time rather than after the damage is done. Engineering managers responsible for developer productivity metrics will pay for the visibility; this isn't a tool the developer buys for themselves.

What to build

A service that connects to a team's CI provider via API, tracks per-module Gradle task duration across every build, detects regressions against a rolling baseline, and posts a comment on the offending PR identifying which module or task caused the slowdown — before the PR is merged.

Where to start

Start with teams already on GitHub Actions or Bitrise who use Gradle Build Scans, since both have clean webhook and API access — avoiding the need to ask customers to change their CI setup before seeing any value.

The hard part

Accurately attributing a build time regression to a specific PR requires enough build history to establish a reliable baseline per branch, and new projects or recently restructured repos won't have enough data to make early alerts trustworthy — meaning the first few weeks of a new customer's experience may produce noisy false positives.

How it makes money

Monthly subscription per CI organization, priced on number of active Android builds per month, with a free tier for teams running under 200 builds per month.