Standing service ci-build-time-budget-kept · revised 11 October 2026
Standing service
Keep your CI pipeline inside an agreed time budget, month after month
We check how long your named pipeline takes against a budget you set, every week, and investigate each overrun. We open one small fix pull request a month, or tell you what only you can change.
This starts a conversation by email. Nothing is charged, and nothing is monitored, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Pipeline duration drifts. A cache key changes, a package is added to a monorepo that builds everything, a test suite grows, or runs wait for a free runner. Each increase is small and nobody notices until people stop waiting for the result. Waiting time and running time also get confused: a queue caused by too few concurrent runners looks like a slow pipeline but needs a different answer.
Who it’s for: A small engineering team whose pipeline was quick once and has slowed down as the code, the dependencies and the number of packages grew, so people wait or skip checks.
Usually starts when: The pipeline's usual duration has crept up, nobody owns it, and the last clean-up faded within weeks.
The result: The pipeline you name stays within the budget agreed in writing for its typical run on the default branch. Each overrun is investigated and either fixed in a pull request, within the monthly allowance, or explained with evidence, and each month you see the weekly checks and how each overrun ended.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target is agreed in writing before it starts, set to what a service at this stage can keep.
The run history is checked once a week, on a day agreed in writing before the service starts, and again when each monthly summary is prepared. At launch the service is not staffed round the clock, so we do not offer round-the-clock cover.
What must remain true
- The named pipeline's typical run on the default branch stays within the agreed budget
- Every overrun ends in a fix pull request within the monthly allowance, or in an explanation with evidence
What we watch
- Run durations for the named pipeline on the default branch, read through a read-only token you create
- The pipeline configuration in the repository
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| At a weekly check, the typical run (the median of the last twenty successful default-branch runs) is longer than the agreed budget. | We split the time into waiting and running, find the step that grew and open the month's included small fix pull request, or tell you what only you can change. Priced as: CI dependency cache that hits |
| A weekly check shows that a change to a monorepo makes every package build for a small edit. | We check how affected packages are detected and tell you what the separate monorepo job would involve; it is larger than the monthly allowance. Priced as: Monorepo: only affected packages |
| A month ends. | We send a short written summary: each weekly check, overruns, the pull request opened and what is still open. |
We do on our own
- Read run history and the pipeline configuration
- Reproduce and investigate on a branch
- Open pull requests that change pipeline files or caching
We ask you first
- Anything that changes runners, plans, concurrency limits or billing
- Merging, or any change to your default branch
- Removing or skipping a test or check to save time
We escalate to you when
- Most of the delay is queueing for runners or a platform limit
- The budget cannot be met without removing checks
- Overruns need more than the one included fix a month
How you know it held. Each month you get, for every weekly check, the typical run and the slow run as defined above, split into waiting and running time where the platform's run data allows, and a link to a run that shows the included fix.
How we keep it true
This service is never finished. Each month's summary shows whether the pipeline stayed inside its budget, and it continues until you end it.
Make one CI pipeline's dependency cache hit when dependencies are unchanged Job Each time it fires
On a re-run with unchanged dependency files, the named pipeline restores its cache and the install step finishes within the target you agreed. A changed lockfile still rebuilds the cache.
At most one a month, as the monthly allowance
The included monthly fix is the size of this job; a second cache fix in the same month is this job at its own price.
Make monorepo CI build and test only the packages a change affects Job Each time it fires
For five agreed test changes, only the packages that depend on the change run their jobs, required checks still report, and the default branch still runs everything.
Bought separately when needed
Narrowing a monorepo's builds is larger than the monthly allowance. We raise it when the history shows it and you buy it as its own job.
What is included, and what is not
- A fix pull request with before and after durations for the one included fix each month, where a small fix applies
- An explanation of what you need to change when the cause is not in the repository
- A written monthly summary
Included
- Monitoring of one named pipeline on one repository's default branch, against a budget in minutes agreed in writing for its typical run
- A typical run means the median duration of the last twenty successful runs of the named pipeline on the default branch; the slow run, the 18th of those twenty durations sorted from shortest to longest, is reported beside it. While fewer than twenty such runs exist, the typical run is the median of those that exist and the slow run is the longest of them
- A check of the run history once a week, on a day agreed in writing, and again when the monthly summary is prepared
- An overrun begins when a weekly check finds the typical run longer than the budget and ends when a later check finds it back inside; a pipeline that stays over for several weeks is one overrun
- Investigation of every overrun. The monthly allowance is one included fix pull request a month for a small fix, meaning a change to a cache key or cache path, or to one job's steps or settings, in the pipeline files of the named pipeline, that does not change which packages or tests run; it does not carry over to the next month
- A plain explanation with evidence when the cause is outside the repository, such as queueing or a platform limit
- A written monthly summary of each weekly check, the overruns and how each ended
Not included
- Merging to your default branch, which stays with your team
- Changing runners, plans, concurrency limits or billing
- Fixes beyond the monthly allowance, and larger fixes such as narrowing which packages a monorepo builds: each is the separate one-off job at its own price, quoted when needed
- Fixing failing jobs: on GitHub Actions that is the existing CI repair and cover; on GitLab CI a job that starts and then fails is not covered by a fixed-price outcome, so ask for a quote
- Rewriting your test suite or restructuring your repository
- A guaranteed duration, a response time or out-of-hours cover
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
For the included fix, the median duration of three runs of the named pipeline on a test branch, on the same runner type, is shorter than the median of three baseline runs and within the agreed budget, with the same jobs and tests executed.
Evidence: Links to the three before and three after runs and a table of durations by step.
No check, test or required job is removed or skipped to meet the budget.
Evidence: The pull request diff and the job lists before and after.
Each month's summary lists, for every weekly check, the typical run and the slow run as defined above, and for every overrun the checks at which it began and ended and how it ended.
Evidence: The written monthly summary, which you can recompute from your own run history.
Sign-off. You review and merge each pull request and read each monthly summary. A fix counts as delivered when you accept it.
If it fails. If we cannot bring an overrun back inside the budget, we say so, explain what we found and what it would take, and it does not use up that month's included fix. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- Your pipeline runs on GitHub Actions or GitLab CI and its configuration is in the repository
- You can create a read-only token or share run history through an authorised route
- You can agree a budget in minutes for a typical run, after we show the current numbers
- A person on your side reviews and merges pull requests
We stop and tell you if
- Most of the time is spent waiting for a runner that you cannot or will not add
- The budget cannot be met without removing tests or checks that you want to keep
- Overruns regularly need more than the one included fix a month, so we agree a different scope with you
What could go wrong
Every fix is a pull request that your team merges, so you can revert it as you would any other change. Ending the service leaves your pipeline as it is, with our open pull requests finished or handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A fix makes the pipeline faster by dropping tests or checks. | We never remove or skip a check to meet the budget; that needs your written approval and is raised as a decision. |
| Queueing for runners is mistaken for slow steps. | We report waiting and running time separately and escalate when the delay is outside the repository. |
| A read-only token gives more access than you intended. | We ask only for run history and a branch or fork. You create and can revoke both at any time. |
Each pull request is checked by a reviewer separate from the work that produced it before it is opened. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review and merge every pull request
- You approve any change to runners, plans or limits
Access we would need
- A read-only token for run history
- Access to a fork or branch for pull requests
Questions
How is this different from keeping CI green?
Keeping CI green is about failures. This is about duration: it watches a time budget and acts when the pipeline slows down, whether or not anything fails. Fixing a failing job is a separate repair.
Do you guarantee a pipeline time?
No. We agree a budget and work to it, but no duration or response time is promised.
What if the delay is waiting for a free runner?
We show the waiting time separately and tell you what only you can change, such as concurrency or plan limits.
What counts as a typical run, a slow run and an overrun?
The typical run is the median duration of the last twenty successful runs on the default branch, and the slow run is the 18th of those twenty durations sorted from shortest to longest. An overrun begins when a weekly check finds the typical run longer than your budget and ends when a later check finds it back inside.
What do I get each month for the fee?
A weekly check of the run history, an investigation of every overrun, one included small fix pull request (a cache change or a change to one job that does not change which packages or tests run; it does not carry over) and the written summary. Larger fixes and further fixes in the same month are the separate one-off jobs at their own prices.
Send an enquiry
Send us
- The repository link and the name of the pipeline you want kept inside a budget
- A rough idea of how long a typical run takes now and how long you would like it to take, in minutes
- Who reviews and merges pull requests
Later, once you agree
- A read-only token or app installation limited to run history for the named pipeline
- Access to a fork or branch we can open pull requests from
- The agreed budget in minutes, the day of the weekly check and the person to tell when something is outside the repository
- Written approval for the repeated runs on a branch that measuring a fix needs
Your repository, runners and secrets stay yours. We read run history with a read-only token you create, and we change files only on a branch or fork through pull requests your team reviews and merges.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “ci-build-time-budget-kept” as the subject.