diff --git a/site/content/en/docs/Getting Started/create-fleetautoscaler.md b/site/content/en/docs/Getting Started/create-fleetautoscaler.md
index bc1ecd7913..68b8ac9555 100644
--- a/site/content/en/docs/Getting Started/create-fleetautoscaler.md	
+++ b/site/content/en/docs/Getting Started/create-fleetautoscaler.md	
@@ -256,8 +256,14 @@ simple-udp-mzhrl-zg9rq   Ready     10.30.64.99    7745    minikube     5m
 ```
 
 {{< alert title="Note" color="info">}}
-If you want to update a `Fleet`, which has `RollingUpdate` replacement strategy and is controlled by a `FleetAutoscaler`, you could omit `Replicas` parameter in a `Fleet` Spec.
-Otherwise fleet would be scaled according to Fleet `Replicas` parameter first and only after certain amount of time it would be rescaled to fit `FleetAutoscaler` `BufferSize` parameter.
+If you want to update a `Fleet` which has `RollingUpdate` replacement strategy and is controlled by a `FleetAutoscaler`:
+1. With `kubectl apply`: you should omit `replicas` parameter in a `Fleet` Spec before re-applying the `Fleet` configuration.
+1. With `kubectl edit`: you should not change the `replicas` parameter in the `Fleet` Spec when updating other field parameters.
+
+If you follow the rules above, then `maxSurge` and `maxUnavaiable` parameters will be used as the RollingUpdate strategy updates your Fleet.
+Otherwise the Fleet would be scaled according to Fleet `replicas` parameter first and only after certain amount of time it would be rescaled to fit `FleetAutoscaler` `BufferSize` parameter.
+
+You could also check the behaviour of the Fleet with Fleetautoscaler on a test `Fleet` to preview what would occur on your production environment.
 {{< /alert >}}
 
 ## Next Steps
diff --git a/site/content/en/docs/Guides/fleet-updates.md b/site/content/en/docs/Guides/fleet-updates.md
index ef55fc5805..2596eb04c8 100644
--- a/site/content/en/docs/Guides/fleet-updates.md
+++ b/site/content/en/docs/Guides/fleet-updates.md
@@ -26,12 +26,26 @@ much of the `Fleet` is  incremented and decremented at one time:
       maxUnavailable: 25%
 ```
 
-So when a Fleet is edited, either through `kubectl` `edit`/`apply` or via the Kubernetes API, this performs the following operations:
+So when a Fleet is edited (any field other than `replicas`, see note below), either through `kubectl` `edit`/`apply` or via the Kubernetes API, this performs the following operations:
 
 1. Adds the `maxSurge` number of `GameServers` to the Fleet.
 1. Shutdown the `maxUnavailable` number of `GameServers` in the Fleet, skipping `Allocated` `GameServers`.
 1. Repeat above steps until all the previous `GameServer` configurations have been `Shutdown` and deleted.
 
+{{< alert title="Note" color="info">}}
+When `Fleet` update contains only changes to the `replicas` parameter, then new GameServers will be created/deleted straight away,
+which means in that case `maxSurge` and `maxUnavailable` parameters for a RollingUpdate will not be used.
+The RollingUpdate strategy takes place when you update `spec` parameters other than `replicas`.
+
+For the case when you want to be flexible on Fleet size, Fleetautoscaler and your prefer `kubectl apply` Fleet config with omitted `replicas` parameter should be used.
+Do not change the `replicas` field manually when you use `kubectl edit fleet` for a fleet which is controlled by a Fleetautoscaler.
+
+[Read Fleetautoscaler guide]({{< relref "../Getting Started/create-fleetautoscaler.md#7-change-autoscaling-parameters" >}}) for more details.
+
+You could also check the behaviour of the Fleet with RollingUpdate strategy on a test `Fleet` to preview your upcoming updates.
+Use `kubectl describe fleet` to track scaling events in a fleet.
+{{< /alert >}}
+
 ## Recreate Strategy
 
 This is an optimal `Fleet` update strategy if you want to replace all `GameServers` that are not `Allocated`