diff --git a/website/source/docs/agent/checks.html.markdown b/website/source/docs/agent/checks.html.markdown
index a2d9ff1572..e6d2bd7a7c 100644
--- a/website/source/docs/agent/checks.html.markdown
+++ b/website/source/docs/agent/checks.html.markdown
@@ -23,7 +23,7 @@ There are five different kinds of checks:
   every 30 seconds). This is similar to the Nagios plugin system. The output of
   a script check is limited to 4K. Output larger than this will be truncated.
   By default, Script checks will be configured with a timeout equal to 30 seconds.
-  It is possible to configure a custom Script check timeout value by specifying the 
+  It is possible to configure a custom Script check timeout value by specifying the
   `timeout` field in the check definition.
 
 * HTTP + Interval - These checks make an HTTP `GET` request every Interval (e.g.
@@ -37,18 +37,19 @@ There are five different kinds of checks:
   limited to roughly 4K. Responses larger than this will be truncated.
 
 * TCP + Interval - These checks make an TCP connection attempt every Interval
-  (e.g. every 30 seconds) to the specified IP/hostname and port. The status of
-  the service depends on whether the connection attempt is successful (ie - the
-  port is currently accepting connections). If the connection is accepted, the
-  status is `success`, otherwise the status is `critical`. In the case of a
-  hostname that resolves to both IPv4 and IPv6 addresses, an attempt will be
-  made to both addresses, and the first successful connection attempt will
-  result in a successful check. This type of check should be preferred over a
-  script that uses `netcat` or another external process to check a simple socket
-  operation. By default, TCP checks will be configured with a request timeout
-  equal to the check interval, with a max of 10 seconds. It is possible to
-  configure a custom TCP check timeout value by specifying the `timeout` field
-  in the check definition.
+  (e.g. every 30 seconds) to the specified IP/hostname and port. If no hostname
+  is specified, it defaults to "localhost". The status of the service depends on
+  whether the connection attempt is successful (ie - the port is currently
+  accepting connections). If the connection is accepted, the status is
+  `success`, otherwise the status is `critical`. In the case of a hostname that
+  resolves to both IPv4 and IPv6 addresses, an attempt will be made to both
+  addresses, and the first successful connection attempt will result in a
+  successful check. This type of check should be preferred over a script that
+  uses `netcat` or another external process to check a simple socket operation.
+  By default, TCP checks will be configured with a request timeout equal to the
+  check interval, with a max of 10 seconds. It is possible to configure a custom
+  TCP check timeout value by specifying the `timeout` field in the check
+  definition.
 
 * <a name="TTL"></a>Time to Live (TTL) - These checks retain their last known state for a given TTL.
   The state of the check must be updated periodically over the HTTP interface. If an
@@ -65,14 +66,14 @@ There are five different kinds of checks:
   last known status of the check across restarts. Persisted check status is
   valid through the end of the TTL from the time of the last check.
 
-* Docker + Interval - These checks depend on invoking an external application which 
-is packaged within a Docker Container. The application is triggered within the running 
-container via the Docker Exec API. We expect that the Consul agent user has access 
-to either the Docker HTTP API or the unix socket. Consul uses ```$DOCKER_HOST``` to 
-determine the Docker API endpoint. The application is expected to run, perform a health 
-check of the service running inside the container, and exit with an appropriate exit code. 
-The check should be paired with an invocation interval. The shell on which the check 
-has to be performed is configurable which makes it possible to run containers which 
+* Docker + Interval - These checks depend on invoking an external application which
+is packaged within a Docker Container. The application is triggered within the running
+container via the Docker Exec API. We expect that the Consul agent user has access
+to either the Docker HTTP API or the unix socket. Consul uses ```$DOCKER_HOST``` to
+determine the Docker API endpoint. The application is expected to run, perform a health
+check of the service running inside the container, and exit with an appropriate exit code.
+The check should be paired with an invocation interval. The shell on which the check
+has to be performed is configurable which makes it possible to run containers which
 have different shells on the same host. Check output for Docker is limited to
 4K. Any output larger than this will be truncated.