diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index ae55d82d7c..5dfe164055 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -1079,13 +1079,15 @@ Explicitly setting this field to 0, will result in cleaning up all the history o
 thus that Deployment will not be able to roll back.
 {{< /note >}}
 
-{{< note >}}
-The cleanup will ONLY start after a deployment reaches a 
-[complete state](/docs/concepts/workloads/controllers/deployment/#complete-deployment)
-For example, if pods are crash looping, and there are multiple rolling updates
+The cleanup only starts **after** a Deployment reaches a 
+[complete state](/docs/concepts/workloads/controllers/deployment/#complete-deployment).
+If you set `.spec.revisionHistoryLimit` to 0, any rollout nonetheless triggers creation of a new
+ReplicaSet before Kubernetes removes the old one.
+
+Even with a non-zero revision history limit, you can have more ReplicaSets than the limit
+you configure. For example, if pods are crash looping, and there are multiple rolling updates
 events triggered over time, you might end up with more ReplicaSets than the 
-`.spec.revisionHistoryLimit` because the deployment never reaches a complete state.
-{{< /note >}}
+`.spec.revisionHistoryLimit` because the Deployment never reaches a complete state.
 
 ## Canary Deployment