diff --git a/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html
index b0f7c94fdc..f151f5a8e2 100644
--- a/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html
+++ b/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html
@@ -27,7 +27,7 @@ description: |-
             <div class="col-md-8">
             <h3>Updating an application</h3>
 
-            <p>Users expect applications to be available all the time, and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. A <b>rolling update</b> allows a Deployment update to take place with zero downtime. It does this by incrementally replacing the current Pods with new ones. The new Pods are scheduled on Nodes with available resources.</p>
+            <p>Users expect applications to be available all the time, and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. A <b>rolling update</b> allows a Deployment update to take place with zero downtime. It does this by incrementally replacing the current Pods with new ones. The new Pods are scheduled on Nodes with available resources, and Kubernetes waits for those new Pods to start before removing the old Pods.</p>
 
             <p>In the previous module we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods).
             In Kubernetes, updates are versioned and any Deployment update can be reverted to a previous (stable) version.</p>