anchor.diff:  --------------------------------------------------
   // NOTCONSOLE
   
  -In this scenario, we can tell that recovery took roughly four minutes.
  -If this were going on for hours, we would be able to watch the
  -`UNASSIGNED` shards drop precipitously.  If that number remained
  -static, we would have an idea that there is a problem.
  -
  -[float]
  -[[timestamp]]
  -==== Why the timestamp?
  -
  -You typically are using the `health` command when a cluster is
  -malfunctioning.  During this period, it's extremely important to
  -correlate activities across log files, alerting systems, etc.
  -
  -There are two outputs.  The `HH:MM:SS` output is simply for quick
  -human consumption.  The epoch time retains more information, including
  -date, and is machine sortable if your recovery spans days.
  +In this example, the recovery took roughly six minutes, from `18:24:06` to
  +`18:30:06`. If this recovery took hours, you could continue to monitor the
  +number of `UNASSIGNED` shards, which should drop. If the number of `UNASSIGNED`
  +shards remains static, it would indicate an issue with the cluster recovery.
positive.code: [[cat-health]]
  === cat health
  
  `health` is a terse, one-line representation of the same information
  from `/_cluster/health`.
  
  [source,js]
  --------------------------------------------------
  
negative.code: --------------------------------------------------
  // NOTCONSOLE
  
  [[cat-health-api-example-large-cluster]]
  ===== Example with a large cluster
  You can use the cat health API to track the recovery of a large cluster over a
  longer period of time. You can do this by including the cat health API request
  in a delayed loop. For example:
  
  [source,sh]
  --------------------------------------------------
  