Merge pull request #197617 from craigshoemaker/patch-3

[Container Apps] Update Health probes

Author: jborsecnik

articles/container-apps/health-probes.md

@@ -15,12 +15,44 @@ Health probes in Azure Container Apps are based on [Kubernetes health probes](ht
 
 Container Apps support the following probes:
 
-- [Liveness](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command): Reports the overall health of your replica.
-- [Startup](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes): Delay reporting on a liveness or readiness state for slower apps with a startup probe.
-- [Readiness](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes): Signals that a replica is ready to accept traffic.
+- **Liveness**: Reports the overall health of your replica.
+- **Readiness**: Signals that a replica is ready to accept traffic.
+- **Startup**: Delay reporting on a liveness or readiness state for slower apps with a startup probe.
+
 
 For a full listing of the specification supported in Azure Container Apps, refer to [Azure REST API specs](https://github.com/Azure/azure-rest-api-specs/blob/main/specification/app/resource-manager/Microsoft.App/stable/2022-03-01/CommonDefinitions.json#L119-L236).
 
+## Default configuration 
+
+Container Apps offers default probe settings if no probes are defined. If your app takes an extended amount of time to start, which is very common in Java, you often need to customize the probes so your container won't crash.
+
+The following example demonstrates how to extend the liveness and readiness probes to accommodate an extended start-up process.
+
+```json
+"probes": [
+       {
+        "type": "liveness",
+        "failureThreshold": 3,
+        "periodSeconds": 10,
+        "successThreshold": 1,
+        "tcpSocket": {
+          "port": 80
+        },
+        "timeoutSeconds": 1
+       },
+       {
+         "type": "readiness",
+         "failureThreshold": 48,
+         "initialDelaySeconds": 3,
+         "periodSeconds": 5,
+         "successThreshold": 1,
+         "tcpSocket": {
+           "port": 80
+          },
+          "timeoutSeconds": 5
+       }
+```
+
 ## HTTP probes
 
 HTTP probes allow you to implement custom logic to check the status of application dependencies before reporting a healthy status. Configure your health probe endpoints to respond with an HTTP status code greater than or equal to `200` and less than `400` to indicate success. Any other response code outside this range indicates a failure.
@@ -152,7 +184,7 @@ containers:
 
 ---
 
-The optional [failureThreshold](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) setting defines the number of attempts Kubernetes tries if the probe if execution fails. Attempts that exceed the `failureThreshold` amount cause different results for each probe. Refer to [Configure Liveness, Readiness and Startup Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for details.
+The optional `failureThreshold` setting defines the number of attempts Container Apps tries if the probe if execution fails. Attempts that exceed the `failureThreshold` amount cause different results for each probe.
 
 ## Next steps