anchor.diff:  <th>Then use this type of health check:</th>
   </tr>
   <tr>
  -<td>can provide an <code>HTTP 200</code> response</td>
  -<td><code>http</code>. The HTTP health check does a GET request to the configured HTTP endpoint. When the health check receives an <code>HTTP 200</code> reponse, the app is declared healthy. If possible, HTTP is the recommended health check mechanism. The advantage of using an HTTP health check is that a healthy HTTP response ensures that the web app is ready to serve HTTP requests. The configured endpoint must respond within 1 second to be considered healthy.</td>
  +<td>Can provide an <code>HTTP 200</code> response</td>
  +<td><code>http</code>: The <code>http</code> health check performs a GET request to the configured http endpoint. When the health check receives an <code>HTTP 200</code> response, the app is declared healthy. We recommend using the <code>http</code> health check type whenever possible. A healthy HTTP response ensures that the web app is ready to serve HTTP requests. The configured endpoint must respond within 1 second to be considered healthy.</td>
   </tr>
   <tr>
  -<td>can receive TCP connections (including HTTP web applications)
  +<td>Can receive TCP connections (including HTTP web applications)
   </td>
   <td>
  -<code>port</code>. A port health check makes a TCP connection to the port or ports configured for the application. For applications with multiple ports, a health check monitors each port. If you do not specify a health check type for your application, then <code>port</code> is used. The TCP connection must be established within 1 second to be considered healthy.</code>
  +<code>port</code>: A health check makes a TCP connection to the port or ports configured for the app. For applications with multiple ports, a health check monitors each port. If you do not specify a health check type for your app, then the monitoring process defaults to a <code>port</code> health check. The TCP connection must be established within 1 second to be considered healthy.</code>
   </td>
   </tr>
   <tr>
  -<td>does not support TCP connections (for example, a worker)</td>
  -<td><code>process</code>. For a process health check, Diego ensures that any process declared for the app stays running. If the process exits, Diego tears down the app instance.</td>
  +<td>Does not support TCP connections (for example, a worker)</td>
  +<td><code>process</code>: For a <code>process</code> health check, Diego ensures that any process declared for the app stays running. If the process exits, Diego stops and deletes the app instance.</td>
   </tr>
   </table>
   
  
positive.code: 
  <strong><%= modified_date %></strong>
  
  ## <a id="about_health_checks"></a> About Application Health Checks
  
  An application health check is a monitoring process that continually checks the status of a running Cloud Foundry application.
  
  When deploying an app, a developer can configure the health check type (port, process, or HTTP), a timeout for starting the application, and an endpoint (for HTTP only) for the application health check.
  
  Application health checks function as part of the app lifecycle managed by [Diego architecture](../../concepts/diego/diego-architecture.html).
  
  
negative.code: 
  ## <a id="setting_health_checks"></a> How to Configure the Health Check for Your Application
  
  Use the [Cloud Controller API](https://apidocs.cloudfoundry.org/251/apps/creating_an_app.html) to configure a health check type, application start timeout, and HTTP endpoint for your app. 
  
  To set the type of health check for your application, you can specify a value in the `health-check-type` field of your [application manifest](./manifest.html#health-check-type) file.
  
  