Apply feedback to resiliency concept page

daprdocs/content/en/concepts/resiliency-concept.md

@@ -26,4 +26,12 @@ Applications can become unresponsive for a variety of reasons. For example, they
 
 Dapr provides a capability for monitoring app health through probes that check the health of your application and react to status changes. When an unhealthy app is detected, Dapr stops accepting new work on behalf of the application.
 
-Read more on how to apply [app health checks]({{< ref app-health >}}) to your application.
+Read more on how to apply [app health checks]({{< ref app-health >}}) to your application.
+
+## Sidecar Health Checks
+Dapr provides a way to determine its health using an [HTTP `/healthz` endpoint]({{< ref health_api.md >}}). With this endpoint, the *daprd* process, or sidecar, can be:
+
+- Probed for its health
+- Determined for readiness and liveness
+
+Read more on about how to apply [dapr health checks]({{< ref sidecar-health >}}) to your application.

daprdocs/content/en/developing-applications/building-blocks/observability/sidecar-health.md

@@ -6,7 +6,7 @@ weight: 200
 description: Dapr sidecar health checks
 ---
 
-Dapr provides a way to [determine its health using an [HTTP `/healthz` endpoint]({{< ref health_api.md >}}). With this endpoint, the *daprd* process, or sidecar, can be:
+Dapr provides a way to determine its health using an [HTTP `/healthz` endpoint]({{< ref health_api.md >}}). With this endpoint, the *daprd* process, or sidecar, can be:
 
 - Probed for its health
 - Determined for readiness and liveness

daprdocs/content/en/operations/resiliency/resiliency-overview.md

@@ -9,8 +9,6 @@ description: "Configure Dapr retries, timeouts, and circuit breakers"
  Resiliency is currently a preview feature. Before you can utilize a resiliency spec, you must first [enable the resiliency preview feature]({{< ref support-preview-features >}}).
 {{% /alert %}}
 
-Distributed applications are commonly comprised of many microservices, with dozens, even hundreds, of instances for any given application. With so many microservices, the likelihood of a system failure increases. For example, an instance can fail or be unresponsive due to hardware, an overwhelming number of requests, application restarts/scale outs, or several other reasons. These events can cause a network call between services to fail. Designing and implementing your application with fault tolerance, the ability to detect, mitigate, and respond to failures, allows your application to recover to a functioning state and become self healing.
-
 Dapr provides a capability for defining and applying fault tolerance resiliency policies via a [resiliency spec]({{< ref "resiliency-overview.md#complete-example-policy" >}}). Resiliency specs are saved in the same location as components specs and are applied when the Dapr sidecar starts.  The sidecar determines how to apply resiliency policies to your Dapr API calls. In self-hosted mode, the resiliency spec must be named `resiliency.yaml`. In Kubernetes Dapr finds the named resiliency specs used by your application. Within the resiliency spec, you can define policies for popular resiliency patterns, such as:
 
 - [Timeouts]({{< ref "policies.md#timeouts" >}})