Anyone who has commissioned a warehouse of AGVs already understands the thing software people call a runner fleet — arguably better than the software people do. Machines with duty cycles. Zoning rules that say where each unit may operate. Telemetry that predicts failures before they strand a load. Maintenance windows nobody enjoys but everyone schedules. The Atlas has a name for the software-side craft: GitLabOps, a coinage of theirs for running delivery on GitLab — informal, nothing certified — and a roboticist reading its runner guidance will nod the whole way through. Below is the audit I would walk onto any floor with — ten checks, written for people who think in fleets, scored in an afternoon, and re-run often enough to matter. None of it requires reading source code; all of it requires the willingness to ask “who approved this?” and wait for a real answer.

Why Robot Teams Should Speak GitLabOps

Because the failure catalogue is identical, only the substrate changes. A job that sits unclaimed because no machine carries its tag is a puck with no AGV assigned. A shared privileged build pool is every robot drawing power from one cable. An unverified image reaching production is an unqualified part installed on a moving arm. Software people call these CI problems; you will recognise them as the classics from AGV and warehouse automation, wearing a text file instead of a shell.

The Ten-Check GitLabOps Fleet Audit

1. Zone the floor by trust. Units that handle protected work must never share a bay with units that handle anything off the street. In GitLab terms: dedicated runners for protected-branch work, deliberately separate from the machinery that builds whatever walks in off the internet.
2. Make build cells disposable. A cell that forgets the previous job is a cell that cannot leak the previous job’s secrets. Ephemeral environments, and runners configured for exactly one execution before replacement — the software equivalent of a sealed battery cassette.
3. Interlock the dangerous modes. Shell executors hand a job direct control of the host machine. For untrusted code that is a robot with its cage door taped open; remove the option rather than posting a warning sign.
4. Check the assignment board. Every job names the machine class it needs by tag. Unclaimed work means the assignment board and the physical floor disagree — reconcile tags against the roster before anyone rewrites a perfectly good script.
5. Read the telemetry, not the vibes. Factory managers track the KPIs that keep a floor honest; software fleets want the same discipline: saturation, queue time, success rate, cost per successful pipeline. Watch them at the 95th percentile rather than the average — averages hide the outlier shifts where everything jams. A fleet flown by feel strands payloads; the numbers strand nothing.
6. Schedule maintenance windows and keep them. The platform itself needs version upgrades on a set rhythm — every six to eight weeks works — stopping at the halfway releases the vendor insists on and letting background migrations wrap up before each hop. Machines that skip maintenance do not skip failures; they merely schedule them for the least convenient shift.
7. Interlock the release path. Protected environments with named approvers, serialised deploys to the same target, superseded deploy jobs rejected, and the production container tag locked to maintainers. These are light curtains for deployment: invisible in daily work, and the only reason everyone still has all ten fingers after a bad release.
8. Audit the credentials locker. Permanent cloud keys stored in CI variables are master keys taped to the lunchroom noticeboard. Replace them with short-lived OIDC identity tokens issued per job, and keep an allowlist that says precisely which services a token may address. When the audit asks who could have touched production storage last quarter, the answer should be a short sentence, not a shrug.
9. Trust the sensors you already have. A retry counter pinned at two on every job is a sensor reporting that something upstream is wrong — do not silence the sensor, trace the vibration. The same logic you apply when sensors get integrated into industrial robots applies to pipeline telemetry: a reading ignored is a reading wasted.
10. Sweep the classic anti-patterns quarterly. One privileged Docker-in-Docker pool for all teams. Blanket retries that launder flaky tests. Stored kubeconfigs handed to any job that asks. The assumption that the Kubernetes executor is automatically the cheaper option — sometimes true, sometimes expensive fiction. Print the list; walk the floor; tick it.

Reading the Audit Results Like an Engineer

Grade with evidence, not with morale. Count the failed checks, assign each an owner and a date, and re-run the audit next quarter to prove the needle moved. An audit without a re-run is a press release; with one, it becomes a maintenance loop, which is the entire culture of good fleet operations in a single sentence. Two numbers deserve standing attention: how much of the fleet sits idle at peak (saturation is spare capacity, which is either safety margin or wasted budget depending on the week) and how far the platform version has drifted from current (two minors is a rule of thumb, five is a confession). The full playbooks and definitions behind these checks live in the Atlas’s GitLabOps page, the reference this audit condenses.

Robotics taught the industry that fleets are governed, not merely used. Delivery platforms reached the same conclusion a decade later, and the vocabulary finally exists for it. Run the ten checks, fix what fails, and your build floor will behave like your best-orchestrated cell: boring, predictable, and quietly profitable. Software teams pay consultants substantial sums to reach the operating discipline your warehouse already runs on — you are simply translating it across the wall.