A `helm rollback` reports success on a 41-service platform chart, yet the incident continues. What does a rollback not restore?

## The one-line model A Helm rollback re-applies a stored manifest. Everything it can restore is inside that YAML; everything else is out of scope, whether or not the incident depends on it. On a large release — a 41-service platform chart, say — that gap is where the second half of an outage lives, because the rollback genuinely succeeded and `helm history` genuinely reads `deployed`. ## Class 1: state the manifest never described A manifest declares objects, not their contents. A document-indexing job that ran under the new revision and rewrote index documents in a shared store has changed data that no rollback touches; the old code now reads records written by the new code. The same holds for files on a PersistentVolume, an external configuration service the app wrote to, a message queue whose offsets moved, a third-party system that was told about the new version. If a revision had side effects beyond the API server, rolling the release back leaves every one of them in place. This is the reason "we can always roll back" is a weaker guarantee than it sounds, and it is why irreversible steps deserve to be sequenced deliberately rather than trusted to a rollback. ## Class 2: objects Helm will not revert Two carve-outs matter here. **CRDs from `crds/`.** Custom resource definitions placed in a chart's `crds/` directory are installed once, before anything else, and are then never templated, never upgraded and never deleted by Helm. A rollback does not put an earlier schema back. If the newer revision widened a CRD and your custom resources were written in the newer shape, rolling back the controllers leaves them facing objects they may not understand. Nothing in the rollback output hints at this. **Kept resources.** Anything annotated `helm.sh/resource-policy: keep` is deliberately excluded from Helm's deletion path, so a rollback that would otherwise remove it leaves it in place — usually correct for stateful things, occasionally surprising. Also note the direction of change on ordinary resources: a rollback deletes objects that exist only in the newer revision and recreates ones the newer revision had removed. Deleting an object is not always cheap. If the newer revision introduced a claim or another stateful object, the rollback removes it — and whatever lived behind it goes with it or is orphaned, depending on how it was declared and what reclaim policy applies. ## Class 3: reverted things you wanted kept This is the class people never anticipate. A chart that renders a Secret from a values key stores that rendered Secret in every revision's manifest. If someone rotated the credential by upgrading with a new value, a rollback to a revision from before the rotation rewrites the Secret back to the **old** credential. Helm did exactly what it was asked; the effect is a silent un-rotation, and consumers holding the new credential start failing minutes later for reasons that look unrelated to the rollback. Worse, pods that took the value as an environment variable keep the value they started with, so half the fleet has one credential and half the other. The same shape applies to anything else that changed forward between the two revisions but is rendered from values: a replica count someone raised during the incident, a feature flag, an allow-list. A rollback is a *whole-release* operation; it cannot revert one service of forty-one and leave the rest alone. ## What "success" actually asserted In Helm 4 the wait strategy defaults to waiting for hooks only, so unless `--wait` was passed the command returned once the API server accepted the manifest. `deployed` therefore means "written", not "running": the restored Deployments may still be pulling images, and the old version may fail to start for the same environmental reason the new one did. Helm 3's separate opt-in `--wait` behaved comparably in that omitting it did not wait for workloads. Either way, the health check after a rollback is on you. ## Working the incident Diff the two revisions' stored manifests before and after rolling back — that tells you precisely which objects the rollback added, removed and mutated, and it is the shortest route to spotting a Secret or a claim in the change set. Then enumerate, deliberately, what the newer revision did that was *not* in that diff: data written, external calls made, CRDs installed. Those are the items that need their own remediation, and they are the ones that keep an incident open after the release ledger says it is closed.