diff --git a/documentation/faq.asciidoc b/documentation/faq.asciidoc
index ec628a27a9..7dc83de22e 100644
--- a/documentation/faq.asciidoc
+++ b/documentation/faq.asciidoc
@@ -137,7 +137,7 @@ The behavior of Debezium varies depending upon which components are stopped or c
 
 The Kafka Connect service is configured to periodically record the position and offsets of each connector. If one of the Kafka Connect service instances in its cluster is _stopped gracefully_, all connectors running in that process will be stopped gracefully (meaning all positions and offsets will be recorded) and those same connectors will be restarted on other Kafka Connect service instances in the same cluster. When those connectors are restarted, they will continue recording events exactly where they left off, with no duplicate events being recorded.
 
-When one of the connectors running in a Kafka Connect service cluster is stopped gracefully, it will complete its current work and record the latest positions and offsets in Kafka. Downstream applications consume from the topics will simply wait until new events are added.
+When one of the connectors running in a Kafka Connect service cluster is stopped gracefully, it will complete its current work and record the latest positions and offsets in Kafka. Downstream applications consuming from the topics will simply wait until new events are added.
 
 If any of the Kafka Connect service instances in its cluster _crashes unexpectedly_, then all connectors that were running in the crashed process will be restarted on other Kafka Connect service instances in the same cluster. However, when those connectors are restarted, they will begin recording events from the database starting at the position/offset _last recorded by the connector before it crashed_. This means the newly-restarted connectors may likely record some of the same events it previously recorded prior to the crash, and these duplicates will always be visible to downstream consuming applications.