Merge pull request #108698 from erichrt/patch-4

Address customer confusion regarding fast probe down behavior

Author: PRMerger12

articles/load-balancer/load-balancer-custom-probe-overview.md

@@ -34,6 +34,9 @@ Health probes support multiple protocols. The availability of a specific health
 >[!IMPORTANT]
 >Load Balancer health probes originate from the IP address 168.63.129.16 and must not be blocked for probes to mark up your instance.  Review [probe source IP address](#probesource) for details.
 
+>[!IMPORTANT]
+>Regardless of configured time-out threshold, HTTP(S) Load Balancer health probes will automatically probe down an instance if the server returns any status code that is not HTTP 200 OK or if the connection is terminated via TCP reset.
+
 ## <a name="probes"></a>Probe configuration
 
 Health probe configuration consists out of the following elements:
@@ -52,22 +55,22 @@ Health probe configuration consists out of the following elements:
 The number of probe responses applies to both
 
 - the number of successful probes that allow an instance to be marked as up, and
-- the number of failed probes that cause an instance to be marked as down.
+- the number of timed-out probes that cause an instance to be marked as down.
 
 The timeout and interval values specified determine whether an instance will be marked as up or down.  The duration of the interval multiplied by the number of probe responses determines the duration during which the probe responses have to be detected.  And the service will react after the required probes have been achieved.
 
-We can illustrate the behavior further with an example. If you have set the number of probe responses to 2 and the interval to 5 seconds, this means 2 probe failures must be observed within a 10 second interval.  Because the time at which a probe is sent is not synchronized when your application may change state, we can bound the time to detect by two scenarios:
+We can illustrate the behavior further with an example. If you have set the number of probe responses to 2 and the interval to 5 seconds, this means 2 probe time-out failures must be observed within a 10 second interval.  Because the time at which a probe is sent is not synchronized when your application may change state, we can bound the time to detect by two scenarios:
 
-1. If your application starts producing a failing probe response just before the first probe arrives, the detection of these events will take 10 seconds (2 x 5 second intervals) plus the duration of the the application starting to signal a failure to when the the first probe arrives.  You can assume this detection to take slightly over 10 seconds.
-2. If your application starts producing a failing probe response just after the first probe arrives, the detection of these events will not begin until the next probe arrives (and fails) plus another 10 seconds (2 x 5 second intervals).  You can assume this detection to take just under 15 seconds.
+1. If your application starts producing a time-out probe response just before the first probe arrives, the detection of these events will take 10 seconds (2 x 5 second intervals) plus the duration of the the application starting to signal a time-out to when the the first probe arrives.  You can assume this detection to take slightly over 10 seconds.
+2. If your application starts producing a time-out probe response just after the first probe arrives, the detection of these events will not begin until the next probe arrives (and times out) plus another 10 seconds (2 x 5 second intervals).  You can assume this detection to take just under 15 seconds.
 
 For this example, once detection has occurred, the platform will then take a small amount of time to react to this change.  This means a depending on 
 
 1. when the application begins changing state and
 2. when this change is detected and met the required criteria (number of probes sent at the specified interval) and
 3. when the detection has been communicated across the platform 
 
-you can assume the reaction to a failing probe will take between a minimum of just over 10 seconds and a maximum of slightly over 15 seconds to react to a change in the signal from the application.  This example is provided to illustrate what is taking place, however, it is not possible to forecast an exact duration beyond the above rough guidance illustrated in this example.
+you can assume the reaction to a time-out probe response will take between a minimum of just over 10 seconds and a maximum of slightly over 15 seconds to react to a change in the signal from the application.  This example is provided to illustrate what is taking place, however, it is not possible to forecast an exact duration beyond the above rough guidance illustrated in this example.
 
 ## <a name="types"></a>Probe types
 
@@ -91,7 +94,7 @@ TCP probes initiate a connection by performing a three-way open TCP handshake wi
 The minimum probe interval is 5 seconds and the minimum number of unhealthy responses is 2.  The total duration of all intervals cannot exceed 120 seconds.
 
 A TCP probe fails when:
-* The TCP listener on the instance doesn't respond at all during the timeout period.  A probe is marked down based on the number of failed probe requests, which were configured to go unanswered before marking down the probe.
+* The TCP listener on the instance doesn't respond at all during the timeout period.  A probe is marked down based on the number of timed-out probe requests, which were configured to go unanswered before marking down the probe.
 * The probe receives a TCP reset from the instance.
 
 The following illustrates how you could express this kind of probe configuration in a Resource Manager template: