docs: tweaks according to latest readme changes (#470)

[Recent changes made to the
README](c330d5f)
should be made to the doc site as well.

Closes #468.

docs/how-to/service-dependencies.md

@@ -191,7 +191,7 @@ service to be started before it, and the `backend` service requires the
 ```{note}
 Currently, `before` and `after` are of limited usefulness, because Pebble only waits 1 second before moving on to start the next service, with no additional checks that the previous service is operating correctly.
 
-If the configuration of `requires`, `before`, and `after` for a service results in a cycle or "loop", an error will be returned when attempting to start or stop the service.
+If the configuration of `before` and `after` for the services results in a cycle, an error will be returned when the Pebble daemon starts (and the plan is loaded) or when a layer that causes a cycle is added.
 ```
 
 % Does it only check that the status is "Active"? So what does `requires` do?

docs/reference/health-checks.md

@@ -140,6 +140,8 @@ Each check can specify a `level` of "alive" or "ready". These have semantic mean
 
 The tool running the Pebble server can make use of this, for example, under Kubernetes you could initialize its liveness and readiness probes to hit Pebble's `/v1/health` endpoint with `?level=alive` and `?level=ready` filters, respectively.
 
-Ready implies alive, and not-alive implies not-ready. If you've configured an "alive" check but no "ready" check, and the "alive" check is unhealthy, `/v1/health?level=ready` will report unhealthy as well, and the Kubernetes readiness probe will act on that.
+If only a "ready" check or only an "alive" check is configured, ready implies alive, and not-alive implies not-ready. If you've configured an "alive" check but no "ready" check, and the "alive" check is unhealthy, `/v1/health?level=ready` will report unhealthy as well, and the Kubernetes readiness probe will act on that.
+
+On the other hand, not-ready does not imply not-alive: if you've configured a "ready" check but no "alive" check, and the "ready" check is unhealthy, `/v1/health?level=alive` will still report healthy.
 
 If there are no checks configured, the `/v1/health` endpoint returns HTTP 200 so the liveness and readiness probes are successful by default. To use this feature, you must explicitly create checks with `level: alive` or `level: ready` in the layer configuration.

docs/reference/layer-specification.md

@@ -101,7 +101,7 @@ services:
         # (Optional) Defines what happens when each of the named health checks
         # fail. Possible values are:
         #
-        # - restart (default): restart the service once
+        # - restart: restart the service once
         # - shutdown: shut down and exit the Pebble daemon (with exit code 11)
         # - success-shutdown: shut down and exit Pebble with exit code 0
         # - ignore: do nothing further
@@ -144,9 +144,9 @@ checks:
         # (Optional) Check level, which can be used for filtering checks when
         # calling the checks API or health endpoint.
         #
-        # For the health endpoint, ready implies alive. In other words, if all
-        # the "ready" checks are succeeding and there are no "alive" checks,
-        # the /v1/health API will return success for level=alive.
+        # For the health endpoint, ready implies alive, and not-alive implies
+        # not-ready (but not the other way around). See the "Health endpoint"
+        # section in the docs for details.
         level: alive | ready
 
         # (Optional) Check is run every time this period (time interval)