How would you set Helm's wait strategy and timeout policy across many teams' delivery pipelines?

## Frame it as a meaning problem, not a flag problem Every version of this decision reduces to one question: **what is a green deploy allowed to claim?** Helm gives you exactly two answers and charges different prices for them. Without a wait strategy, `helm upgrade` returns once the API server has accepted the manifests and any hooks have run. That is fast, it never produces a false failure, and it proves nothing about whether the application is running. With a wait strategy, the exit code means the release converged to a state the cluster reports as good - which is what most people believe the first answer already means. Neither is right everywhere, and a platform that mandates one of them fleet-wide is choosing a meaning on behalf of teams whose situations differ. ## Where waiting earns its cost Wait when **the next thing that happens depends on the release being live**: a smoke-test stage, a traffic shift, a second chart that assumes the first is serving, a release train that must not advance on a broken step. In those pipelines, not waiting simply relocates the failure to a later stage where it is harder to attribute. Do not wait when the pipeline's job ends at "the desired state has been submitted" - most obviously when a reconciler or a human owns what happens next, and the deploy step is just handing over. Paying a rollout's worth of CI minutes to learn something nobody in that pipeline acts on is pure cost. The cost is real and it compounds. A pipeline that deploys several charts serially adds up every wait; hold a runner for the 7m14s an invoice-rendering worker's rollout genuinely takes, times a dozen services, and you have bought a queue. Waiting is a capacity decision as much as a correctness one, and it belongs in the same conversation as runner sizing. ## Budget timeouts per chart, from data The single most common failure of governance here is one org-wide timeout. It is always wrong in both directions at once: too tight for the slow chart with a large image and a warm-up, too loose for the small one where a genuinely stuck rollout should be caught in ninety seconds. The workable policy is a **per-chart budget derived from that chart's observed rollout time plus headroom**, reviewed when the workload changes shape. That chart with a 7m14s p95 gets something like twelve minutes; a stateless API that is ready in forty seconds gets three. Two constraints ride along: the surrounding CI step's own limit must exceed Helm's, or you lose Helm's diagnostic error to a job kill; and a very large budget must be treated as a defect to investigate rather than a setting, because it usually means a readiness signal that never settles and a pipeline that has quietly stopped reporting. ## Decide what a timeout obliges A wait strategy manufactures a new event class: **a release that Helm has recorded as failed but that may be perfectly healthy thirty seconds later**, because the cluster kept converging after Helm stopped watching. If nobody owns that event, teams learn to re-run the pipeline until it is green, and you have added flakiness while believing you added rigour. So the policy has to say what happens next: who looks, what they check, and what the pipeline does with the failed revision. Whether anything is automatically undone is a separate flag's decision and a separate conversation - the point here is that "we turned on waiting" is not a finished policy until the timeout has an owner. ## Standardise the strategy, time-box the exception Pick `watcher` as the estate default: status-driven readiness generalises to the custom resources charts increasingly install, and being event-driven it is far kinder to the API server than a poll loop across a large release. Treat `legacy` as a **migration exception with an expiry date**, granted to a team whose chart the two strategies judge differently, so that the exception is a ticket rather than a permanent fork in how your estate defines readiness. ## What I would actually ship A small set of defaults in the shared pipeline template - wait on, watcher, a required per-chart timeout with no fallback value, and the CI step limit derived from it - plus a documented opt-out for the hand-over pipelines, plus a dashboard of timed-out releases. The dashboard is the part people skip and the part that tells you whether the policy is working: a chart that times out regularly is either mis-budgeted or genuinely unhealthy, and both deserve a person.