diff --git a/v2:-Documentation.md b/v2:-Documentation.md
index 43f979f..c044f69 100644
--- a/v2:-Documentation.md
+++ b/v2:-Documentation.md
@@ -149,10 +149,15 @@ If `--environ` is specified, the environment as seen by the Caddy process will b
 ## stop
 
 ```
-$ caddy stop
+$ caddy stop [--address <interface>]
 ```
 
-Gracefully stops the running Caddy process. (Note: this will stop any process named the same as the executable.) On Windows, this stop is forceful and Caddy will not have an opportunity to clean up any active locks; for a graceful shutdown on Windows, use Ctrl+C or the [/stop endpoint](#post-stop).
+Gracefully stops the running Caddy process (other than the process for the stop command) and causes it to exit.
+
+It first tries to use the admin API (at its default address, or you can customize it with the `--address` flag) to perform a graceful shutdown. In other words, it simply performs a request to the [/stop endpoint](#post-stop). If that fails for any reason, it will look for any other process named the same as the current binary (i.e. `os.Args[0]`) and signal it to stop gracefully. On Windows, such a stop is foreful and Caddy will not have an opportunity to clean up any active locks.
+
+If you want to stop the current configuration but do not want to exit the process, use the admin API: [`DELETE /config/`](#delete-configscope).
+
 
 ## reload
 
@@ -305,7 +310,7 @@ $ curl -X POST "http://localhost:2019/load" \
 
 ## POST /stop
 
-Gracefully shuts down the server and exits the process. To only shut down the running configuration, use [`DELETE /config/`](#delete-configscope).
+Gracefully shuts down the server and exits the process. To only stop the running configuration without exiting the process, use [`DELETE /config/`](#delete-configscope).
 
 ### Example
 
@@ -467,8 +472,8 @@ All contexts support the global placeholders:
 	The system's filepath separator
 {time.now.common_log}
 	The current timestamp in Common Log Format
-{env.variable_name}
-	Replace variable_name with any env variable (lowercase)
+{env.VARIABLE_NAME}
+	Replace VARIABLE_NAME with any env variable
 ```
 
 ## Config adapters
@@ -1274,13 +1279,13 @@ Within an HTTP route, you can use additional placeholders:
 {http.request.uri.path.dir}
 	The directory, excluding leaf filename
 {http.request.uri.query.PARAM}
-	A specific query string parameter given by PARAM
+	A specific query string parameter given by PARAM (not all caps)
 {http.request.header.FIELD-NAME}
-	Request header field name (lower-cased)
+	Request header field name (not all caps)
 {http.request.cookie.COOKIE_NAME}
-	Request cookie name (lower-cased)
+	Request cookie name (not all caps)
 {http.response.header.FIELD-NAME}
-	Response header field name (lower-cased)
+	Response header field name (not all caps)
 ```
 
 If you are using regexp matchers, capture groups (both named and numeric) are available as well:
@@ -1873,7 +1878,7 @@ A highly flexible and configurable multi-host reverse proxy with load balancing,
 - `load_balancing.try_duration`: How long to try selecting available backends for each request if the next available host is down. By default, this retry is disabled. Clients may hang for this long while the load balancer tries to find an available upstream host.
 - `load_balancing.try_interval`: How long to wait between selecting the next host from the pool. Default is 250ms. Only relevant when a request to an upstream host fails. Be aware that setting this to 0 with a non-zero `try_duration` can cause the CPU to spin if all backends are down and latency is very low.
 - `load_balancing.retry_match`: A list of matcher sets that restricts with which requests retries are allowed. A request must match any of the given matcher sets in order to be retried if the connection to the upstream succeeded but the subsequent round-trip failed. If the connection to the upstream failed, a retry is always allowed. If unspecified, only GET requests will be allowed to be retried. Note that a retry is done with the next available host according to the load balancing policy.
-- `health_checks`: Configures active and passive health checks. Active health checks run in the background on a timer, whereas passive health checks monitor proxied requests. One of path or port must be set to enable them.
+- `health_checks`: Configures active and passive health checks. Active health checks run in the background on a timer, whereas passive health checks monitor proxied requests. To minimally enable active health checks, set either path or port (or both). To minimally enable passive health checks, specify at least an empty config object.
 - `health_checks.active.path`: The URI path to use for health checks.
 - `health_checks.active.port`: The port to use (if different from dial address) for health checks.
 - `health_checks.active.interval`: How frequently to perform active health checks (default 30s).