Learn
Health-gated deployment, explained.
A health gate is a rule that decides whether a release is allowed to reach more machines. The interesting part is not the rule, it is what the rule is allowed to count as evidence.
Gates, and what they measure
A staged rollout without a gate is just a slow rollout. The gate is the part that decides whether stage two happens at all, and the quality of a deployment system is mostly the quality of that decision.
In server infrastructure the decision is usually time plus error rate: push to five percent, wait fifteen minutes, check that errors did not rise, continue. This works because the machines are reachable and continuously reporting. Absence of data is itself an alarm, and it fires within seconds.
Take the same rule to a fleet where machines are legitimately dark half the time and it inverts. The gate now passes fastest when the fewest machines are talking, because nothing has reported a problem. It is not a weak signal, it is an actively misleading one.
Evidence, not elapsed time
| Rule | What it actually asserts |
|---|---|
| Wait 24 hours, then advance | That 24 hours passed. On a fleet that is mostly offline, this asserts nothing about the release. |
| Advance when 20 units confirm healthy | That 20 machines ran the new image, judged themselves against real checks and said so. This is a claim about the release. |
| Halt if any unit self-reverts | That no machine found the new build bad enough to save itself. A single self-revert is stronger evidence than a thousand quiet units. |
| Halt if check-ins drop below baseline | That the release did not break connectivity. This is the one thing the fleet can detect that no individual robot can report, by definition. |
| Ignore units dark beyond 72 hours | That long-dark machines are unknown, not healthy. They leave the denominator so the gate is honest about its sample. |
Choosing signals worth gating on
Mission metrics beat service checks
Every process being up tells you the release started. Whether the machine still does its job tells you the release worked. Obstacle response time, tracking error and throughput are the signals that catch real regressions.
Connectivity belongs in the checks
A release that breaks the network path looks identical to a healthy one from the cloud's point of view, right up until you need to fix it. Making getting back online a condition turns that failure self-correcting.
Compare against the unit's own history
Fleets are heterogeneous enough that absolute thresholds either fire constantly or never. Baselines per ring, over a couple of weeks, are what make a five percent regression detectable.
Where gates fall short
The honest list
- A gate cannot watch a signal nobody collects. Most gate design work is actually telemetry work.
- A gate cannot distinguish a bad release from a bad week. If throughput drops during a peak season, the gate will halt, and it should, but a human still has to look.
- Tight gates on a small ring produce false halts. Twenty confirmations out of a ring of twenty four means a couple of unlucky units stop everything.
- A gate is not a substitute for testing. It catches what escaped, and the canary ring is where you learn what your bench coverage missed.
- No gate helps if the rollout can be bypassed by hand. A field engineer with a laptop is outside the system unless the system is the easier path.
Early access
Running robots in the field?
We are taking on a handful of fleets this year, in agriculture, inspection, drones and logistics. Few enough that you get direct engineering time rather than a support queue.
Founding customers get direct engineering time and a permanent founding rate.