Report
How a small firm ships: deploy and release runs, May to August 2026
A buyer of engineering work wants to know how often a firm puts change in front of its users, how much of that is routine, and what the firm counts as a release. Four months of our own run record, counted by a rule anyone can apply to theirs.
- Runs of 1 May to 31 Aug 2026, read 8 Sep 2026
- First published 8 Sep 2026, this edition 29 Oct 2026
- PDF, 6 pages, 232 KB
- BS-RPT-13, version 1.1
Executive summary
Our deploy and release workflows ran 1,261 times from 1 May to 31 August 2026, and 772 of those runs succeeded.
May had the most successful runs of the four months, 252; June had 120, July 212 and August 188.
A deploy count answers the question a buyer of engineering work should ask first: whether the firm ships as a habit or as an event. A firm that releases a few times a year treats each release as a project, with a freeze before it and a scramble after it. A firm that releases many times a week has made release the ordinary end of a change, which is what makes small changes safe to make and faults quick to reverse.
Of the 772 successful runs, 771 started from a push to a branch or from a person dispatching the workflow by hand: 628 on a push and 143 on a dispatch. A deploy that starts from a push is a merge going live on its own, with the review and the tests already behind it. That is the property the count is for.
Runs that did not succeed stay in the total. Of the 489 runs that did not succeed, 288 failed, 146 were cancelled when a later push replaced them and 55 were skipped by their own conditions. A failed run is a deploy that stopped itself before the change reached a user, and the count stays in the total because a buyer should be able to look at it.
- Count your own deploys by a written rule, from the run record, and keep the runs that did not succeed in the count.
- Make the push the trigger for every ordinary release, and be able to say which releases still need a person to start them.
- Ask every supplier that builds or hosts software for you for the same count, by the same rule.
Report
The figures
Deploy and release runs by month, May to August 2026
What to do
- Write the rule down: which workflow names count as a release, which triggers count, and which repositories are yours.
- Count the last four full months from the run record, every run and the successes, and bucket them by month.
- Make the push the trigger for every ordinary release, and list the cases that still need a hand on the button.
- Put a smoke test at the end of every deploy so a failed release stops itself, and make a rollback a deploy of the previous version.
- Keep the runs that did not succeed in the count, and look hard at any month where the gap widens.
- Put the same gates in the path of every push: review, tests, a secret scan and a dependency check, so a release by push is also the most checked release.
- Ask every supplier that builds or hosts software for you for the same count, by the same rule, and read the months with the fewest runs first.
We build and run platforms for Australian organisations on this cadence: small changes, reviewed before the merge, tested on the branch and deployed by the push, with security designed in from the first commit. An engineering engagement with us starts with the same count run on your repositories and ends with a release path your team runs on its own. Scope and price are at blackshard.com.au/services/engineering, and the secure build offer at blackshard.com.au/solutions/secure-build.
Method
The count comes from the run record every modern build service keeps: one row per workflow run, with the name of the workflow, what started it, when it started and how it ended. We read it for the four full months from 1 May to 31 August 2026 and applied one rule to every row.
A run counts when the workflow behind it is named for deploy, release, ship or publish and for none of check, status or preview, and it counts as successful when the build service recorded its conclusion as success; runs in forks and mirrors of other people’s repositories are left out.
A run the service raised on its own, with no workflow file behind it, is left out. Runs that failed, runs cancelled because a later push replaced them, and runs skipped by their own conditions stay in the total and nowhere else. Months are calendar months in Coordinated Universal Time, the clock the record keeps, and a run belongs to the month it started.
The rule is narrow on purpose. A build that compiles and tests a change is work, and a status check on a pull request is work, but neither puts anything in front of a user. Counting them would double the figure and tell a buyer nothing about how often the product changes. The rule also hides nothing that failed: a count of successes with the attempts left out is a figure a buyer should distrust.
The same rule runs on any run record. Export the runs for four full months, keep the rows whose workflow name passes the word test, drop the forks, bucket by the month each run started, and count the total and the successes in each bucket.
BS-RPT-13, published 8 Sep 2026, revised 29 Oct 2026
The full report, as a PDF
PDF, 6 pages, 232 KB. Runs of 1 May to 31 Aug 2026, read 8 Sep 2026.
More reports
Report
Security events by hour: what our monitoring sees
Measured 26 Oct 2026, 00:45 AEST · PDF, 6 pages, 213 KB
