diff --git a/developing-with-nats/connecting/connect_timeout.md b/developing-with-nats/connecting/connect_timeout.md
index f4b3a9e..1c4ed7a 100644
--- a/developing-with-nats/connecting/connect_timeout.md
+++ b/developing-with-nats/connecting/connect_timeout.md
@@ -1,6 +1,6 @@
 # Setting a Connect Timeout
 
-Each library has its own, language preferred way, to pass connection options. One of the most common options is a connect timeout. It limits how long it can take to established a connection to a server. Should multiple URLs be provided, this timeout applies to each cluster member individually. To set the maximum time to connect to a server to 10 seconds:
+Each library has its own, language preferred way, to pass connection options. One of the most common options is a connect timeout. It limits how long it can take to establish a connection to a server. Should multiple URLs be provided, this timeout applies to each cluster member individually. To set the maximum time to connect to a server to 10 seconds:
 
 {% tabs %}
 {% tab title="Go" %}
diff --git a/developing-with-nats/events/slow.md b/developing-with-nats/events/slow.md
index 7dd837a..8cd8e6e 100644
--- a/developing-with-nats/events/slow.md
+++ b/developing-with-nats/events/slow.md
@@ -2,7 +2,7 @@
 
 NATS is designed to move messages through the server quickly. As a result, NATS depends on the applications to consider and respond to changing message rates. The server will do a bit of impedance matching, but if a client is too slow the server will eventually cut them off by closing the connection. These cut off connections are called _slow consumers_.
 
-One way some of the libraries deal with bursty message traffic is to buffer incoming messages for a subscription. So if an application can handle 10 messages per second and sometimes receives 20 messages per second, the library may hold the extra 10 to give the application time to catch up. To the server, the application will appear to be handling the messages and consider the connection healthy. It is up to the client library to decide what to do when the cache is too big, but most client libraries will drop incoming messages.
+One way some of the libraries deal with bursty message traffic is to buffer incoming messages for a subscription. So if an application can handle 10 messages per second and sometimes receives 20 messages per second, the library may hold the extra 10 to give the application time to catch up. To the server, the application will appear to be handling the messages and consider the connection healthy. Most client libraries will notify the application that there is a SlowConsumer error and discard messages.
 
 Receiving and dropping messages from the server keeps the connection to the server healthy, but creates an application requirement. There are several common patterns: