diff --git a/daprdocs/content/en/developing-applications/building-blocks/observability/app-health.md b/daprdocs/content/en/developing-applications/building-blocks/observability/app-health.md
index aa36b64e5..cd9f1b385 100644
--- a/daprdocs/content/en/developing-applications/building-blocks/observability/app-health.md
+++ b/daprdocs/content/en/developing-applications/building-blocks/observability/app-health.md
@@ -28,7 +28,7 @@ App health checks are disabled by default.
 
 App health checks in Dapr are meant to be complementary to, and not replace, any platform-level health checks, like [liveness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) when running on Kubernetes.  
 
-Platform-level health checks (or liveness probes) generally ensure that the application is running, and cause the platform to restart the application (or, in case of Kubernetes, pod) in case of failures.  
+Platform-level health checks (or liveness probes) generally ensure that the application is running, and cause the platform to restart the application (or, in case of Kubernetes, a failing App Health check won't remove a pod from Service Discovery and that this remains the responsibility of the kubernetes liveness probe, and NOT Dapr) in case of failures.  
 Unlike platform-level health checks, Dapr's app health checks focus on pausing work to an application that is currently unable to accept it, but is expected to be able to resume accepting work *eventually*. Goals include:
 
 - Not bringing more load to an application that is already overloaded.