Per-server rollout
Which box got which version, in what order, and rolling one back to its last known good.
Delivery → Deployments → Fleet records a deploy per server rather than as one event.
Why it matters
A deploy that reached four of six servers is not "deployed" and is not "failed". It is a state that ordinary deploy tracking cannot express — and it is exactly the state that produces the most confusing incidents, because half the fleet behaves differently from the other half.
What is recorded
| Per server | Version, start, finish, outcome |
| Order | Which box went first |
| Duration | Per server |
| Failures | Which ones, and why |
Ordering is the diagnosis
When errors start on the three servers that were deployed first and not on the rest, you have your answer in one look. That is the strongest available signal that a deploy caused something, and it requires knowing the order.
Last known good
Each server records the last version that deployed and passed its health window. Rolling back returns that server to its own last known good.
Per server, not fleet-wide. A server that has been failing to deploy for two releases has a different last known good from one that was fine until an hour ago, and rolling both to the same version is wrong for one of them.
Partial rollback
Roll back only the affected servers. A canary that went badly does not require the whole fleet to move.
Related
- Servers — the machines
- Agent rollout — the same staged idea, for the agent itself
- Pipelines — automatic rollback on a failed health window
Where this behaviour lives: frontend/src/app/deployments/fleet/, backend/internal/service/deploy_fleet_svc.go. If the code and this page disagree, the code is right — please fix the page.
Part of Delivery — Deployments, pipelines, releases and everything that ships code.