diff --git a/docs/docs/concepts/index.html b/docs/docs/concepts/index.html
index c1af21f2d..5b557c913 100644
--- a/docs/docs/concepts/index.html
+++ b/docs/docs/concepts/index.html
@@ -311,7 +311,7 @@ <h2 id="segments">Segments</h2>
 
 <p>Reaper splits repair runs in segments. A segment is a subrange of tokens that fits entirely in one of the cluster token ranges. The minimum number of segments for a repair run is the number of token ranges in the cluster. With a 3 nodes cluster using 256 vnodes per node, a repair run will have at least 768 segments. If necessary, each repair can define a higher number of segments than the number of token ranges.</p>
 
-<p><strong>Starting with Reaper 1.2.0 and Cassandra 2.2, token ranges that have the same replicas can be coalesced into a single segment.</strong> If the total number of requested segments is lower than the number of vnodes, Reaper will try to group token ranges so that each segment has the appropriate number of tokens.
+<p><strong>As of Reaper 1.2.0 and Apache Cassandra 2.2, token ranges that have the same replicas can be consolidated into a single segment.</strong> If the total number of requested segments is lower than the number of vnodes, Reaper will try to group token ranges so that each segment has the appropriate number of tokens.
 In Cassandra 2.2, one repair session will be started for each subrange of the segment, so the gain will be the reduction of overhead in Reaper. Starting with 3.0, Cassandra will generate a single repair session for all the subranges that share the same replicas, which then further reduces the overhead of vnodes in Cassandra.</p>
 
 <h2 id="back-pressure">Back-pressure</h2>
diff --git a/docs/docs/configuration/docker_vars/index.html b/docs/docs/configuration/docker_vars/index.html
index 73ad02d53..057945b92 100644
--- a/docs/docs/configuration/docker_vars/index.html
+++ b/docs/docs/configuration/docker_vars/index.html
@@ -590,7 +590,7 @@ <h2 id="direct-mapping-to-reaper-specific-configuration-settings">Direct Mapping
 
 <tr>
 <td><code>REAPER_LOGGING_FORMAT</code></td>
-<td><code>REAPER_LOGGING_APPENDERS_LOG_FORMAT</code></td>
+<td><code>REAPER_LOGGING_APPENDERS_CONSOLE_LOG_FORMAT</code></td>
 </tr>
 
 <tr>
diff --git a/src/docs/content/docs/concepts.md b/src/docs/content/docs/concepts.md
index 043bd8b85..4a0988572 100644
--- a/src/docs/content/docs/concepts.md
+++ b/src/docs/content/docs/concepts.md
@@ -10,7 +10,7 @@ weight = 5
 
 Reaper splits repair runs in segments. A segment is a subrange of tokens that fits entirely in one of the cluster token ranges. The minimum number of segments for a repair run is the number of token ranges in the cluster. With a 3 nodes cluster using 256 vnodes per node, a repair run will have at least 768 segments. If necessary, each repair can define a higher number of segments than the number of token ranges.
 
-**Starting with Reaper 1.2.0 and Cassandra 2.2, token ranges that have the same replicas can be coalesced into a single segment.** If the total number of requested segments is lower than the number of vnodes, Reaper will try to group token ranges so that each segment has the appropriate number of tokens.
+**As of Reaper 1.2.0 and Apache Cassandra 2.2, token ranges that have the same replicas can be consolidated into a single segment.** If the total number of requested segments is lower than the number of vnodes, Reaper will try to group token ranges so that each segment has the appropriate number of tokens.
 In Cassandra 2.2, one repair session will be started for each subrange of the segment, so the gain will be the reduction of overhead in Reaper. Starting with 3.0, Cassandra will generate a single repair session for all the subranges that share the same replicas, which then further reduces the overhead of vnodes in Cassandra.
 
 ## Back-pressure
diff --git a/src/docs/content/docs/configuration/docker_vars.md b/src/docs/content/docs/configuration/docker_vars.md
index 7d4a556a4..cbb2e0a14 100644
--- a/src/docs/content/docs/configuration/docker_vars.md
+++ b/src/docs/content/docs/configuration/docker_vars.md
@@ -67,7 +67,7 @@ Some variable names have changed between the release of Docker-support and Reape
 `REAPER_JMX_USERNAME` | `REAPER_JMX_AUTH_USERNAME`
 `REAPER_JMX_PASSWORD` | `REAPER_JMX_AUTH_PASSWORD`
 `REAPER_LOGGERS` | `REAPER_LOGGING_LOGGERS`
-`REAPER_LOGGING_FORMAT` | `REAPER_LOGGING_APPENDERS_LOG_FORMAT`
+`REAPER_LOGGING_FORMAT` | `REAPER_LOGGING_APPENDERS_CONSOLE_LOG_FORMAT`
 `REAPER_APP_PORT` | `REAPER_SERVER_APP_PORT`
 `REAPER_APP_BIND_HOST` | `REAPER_SERVER_APP_BIND_HOST`
 `REAPER_ADMIN_PORT` | `REAPER_SERVER_ADMIN_PORT`