diff --git a/nats_admin/upgrading_cluster.md b/nats_admin/upgrading_cluster.md
index 98946cc..fe7e1ae 100644
--- a/nats_admin/upgrading_cluster.md
+++ b/nats_admin/upgrading_cluster.md
@@ -1,6 +1,6 @@
 ## Cluster Upgrading
 
-The basic strategy for upgrading a cluster revolves around the server's ability to gossip cluster configuration to clients and other servers. When cluster configuration changes, clients become aware of new servers automatically. In case of a disconnect, a client has a list of servers that joined the cluster in addition to the ones it knew about from its connection settings. 
+The basic strategy for upgrading a cluster revolves around the server's ability to gossip cluster configuration to clients and other servers. When cluster configuration changes, clients become aware of new servers automatically. In the case of a disconnect, a client has a list of servers that joined the cluster in addition to the ones it knew about from its connection settings. 
 
 Note that since each server stores it's own permission and authentication configuration, new servers added to a cluster should provide the same users and authorization to prevent clients from getting rejected or gaining unexpected privileges.
 
@@ -36,7 +36,7 @@ nats-sub -s nats://localhost:4222 ">"
 
 `nats-sub` is a subscriber sample included with all NATS clients. `nats-sub` subscribes to a subject and prints out any messages received. You can find the source code to the go version of `nats-sub` [here)(https://github.com/nats-io/nats.go/tree/master/examples).  After starting the subscriber you should see a message on 'A' that a new client connected.
 
-We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A,' let's introduce a new server 'T.'  Server 'T' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go besides 'A.'  and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about ["Avoiding the Thundering Herd"](/developer/reconnect/random.md/).
+We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A,' let's introduce a new server 'T.'  Server 'T' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go other than 'A.' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about ["Avoiding the Thundering Herd"](/developer/reconnect/random.md/).
 Suffice it to say that clients redistribute themselves about evenly between all servers in the cluster. In our case 1/2 of the clients on 'A' will jump over to 'B' and the remaining half to 'T.'
 
 Let's start our temporary server: