Merge pull request #10576 from MicrosoftDocs/main

Auto Publish – main to live - 2026-01-22 18:00 UTC

Author: learn-build-service-prod[bot]

support/azure/app-service/web-apps-performance-faqs.md

@@ -15,7 +15,7 @@ ms.custom: sap:Availability, Performance, and Application Issues
 
 ## Summary
 
-This article answers common questions about availability, performance, and troubleshooting application issues in the [Web Apps feature of Azure App Service](https://azure.microsoft.com/services/app-service/web/). Use this guide to quickly resolve problems and optimize your app’s reliability.
+This article has answers to frequently asked questions (FAQs) about application performance issues for the [Web Apps feature of Azure App Service](https://azure.microsoft.com/services/app-service/web/).
 
 ## Where can I learn more about quotas and limits for various App Service plans?
 
@@ -145,3 +145,4 @@ To turn on failed request tracing, follow these steps:
 - If you're deploying in regions that support availability zones, consider enabling zone redundancy to enhance resiliency during regional outages. For more information, see [Reliability in Azure App Service](/azure/reliability/reliability-app-service).
 
 - App Service undergoes routine maintenance to ensure platform reliability. For more control over update behavior, especially in App Service Environment v3, configure upgrade preference.  For more information, see [Routine (planned) maintenance for Azure App Service](/azure/app-service/routine-maintenance).
+

support/azure/kubernetes-fleet/cluster-resource-placement/crp-clusterresourceplacementapplied-false.md

@@ -1,37 +1,73 @@
 ---
-title: ClusterResourcePlacementApplied failure when using ClusterResourcePlacement API object in Azure Kubernetes Fleet Manager
-description: Helps you resolve ClusterResourcePlacementApplied failure when you propagate resources by using the ClusterResourcePlacement API object in Azure Kubernetes Fleet Manager APIs.
-ms.date: 08/05/2024
+title: PlacementApplied failure when using placement APIs in Azure Kubernetes Fleet Manager
+description: Helps you resolve ClusterResourcePlacementApplied or ResourcePlacementApplied failure when you propagate resources by using the ClusterResourcePlacement or ResourcePlacement API object in Azure Kubernetes Fleet Manager APIs.
+ms.date: 12/09/2025
 ms.reviewer: zhangryan, chiragpa, shasb, ericlucier, arfallas, sachidesai
 ms.service: azure-kubernetes-fleet-manager
 ms.custom: sap:Other issue or questions related to Fleet manager
 ---
 
-# Resource propagation failure: ClusterResourcePlacementApplied is False
+# Resource propagation failure: PlacementApplied is False
 
-This article discusses how to troubleshoot `ClusterResourcePlacementApplied` issues when you propagate resources by using the `ClusterResourcePlacement` object API in Microsoft Azure Kubernetes Fleet Manager.
+## Summary
+
+This article discusses how to troubleshoot resource application failures when you propagate resources by using placement APIs in Microsoft Azure Kubernetes Fleet Manager. This issue applies to both `ClusterResourcePlacement` and `ResourcePlacement`, each with their own dedicated custom resource condition types:
+
+- `ClusterResourcePlacementApplied` for ClusterResourcePlacement
+- `ResourcePlacementApplied` for ResourcePlacement
+
+Sample error messages:
+
+# [ClusterResourcePlacement](#tab/clusterresourceplacement)
+
+```yaml
+  - lastTransitionTime: "2024-05-07T23:32:40Z"
+    message: Failed to apply resources to 1 clusters, please check the `failedPlacements` status
+    observedGeneration: 1
+    reason: ApplyFailed
+    status: "False"
+    type: ClusterResourcePlacementApplied
+```
+
+# [ResourcePlacement](#tab/resourceplacement)
+
+```yaml
+  - lastTransitionTime: "2024-05-07T23:32:40Z"
+    message: Failed to apply resources to 1 clusters, please check the `failedPlacements` status
+    observedGeneration: 1
+    reason: ApplyFailed
+    status: "False"
+    type: ResourcePlacementApplied
+```
+
+---
 
 ## Symptoms
 
-When you use the `ClusterResourcePlacement` API object in Azure Kubernetes Fleet Manager to propagate resources, the deployment fails. The `ClusterResourcePlacementApplied` status shows as `False`.
+When you use the `ClusterResourcePlacement` or `ResourcePlacement` API object in Azure Kubernetes Fleet Manager to propagate resources, the deployment fails. The `ClusterResourcePlacementApplied` (for ClusterResourcePlacement) or `ResourcePlacementApplied` (for ResourcePlacement) status shows as `False`.
+
+> [!NOTE]
+> To get more information about why the resources aren't applied, you can check the work applier controller logs. For more information about viewing Fleet agent logs, see [View agent logs in Azure Kubernetes Fleet Manager](/azure/kubernetes-fleet/view-fleet-agent-logs).
 
 ## Cause
 
-This issue might occur because of one of the following reasons:
+One of the following reasons might cause the issue:
 
-- The resource already exists on the cluster and isn't managed by the fleet controller. To resolve this issue, update the `ClusterResourcePlacement` manifest YAML file to use `AllowCoOwnership` within `ApplyStrategy` to allow the fleet controller to manage the resource.
-- Another `ClusterResourcePlacement` deployment is already managing the resource for the selected cluster by using a different apply strategy.
-- The `ClusterResourcePlacement` deployment doesn't apply the manifest because of syntax errors or invalid resource configurations. This might also occur if a resource is propagated through an envelope object.
+- The resource already exists on the cluster and the fleet controller doesn't manage it.
+- Another placement (ClusterResourcePlacement or ResourcePlacement) already manages the resource for the selected cluster by using a different apply strategy.
+- The placement doesn't apply the manifest because of syntax errors or invalid resource configurations. A resource propagated through an envelope object might also cause the issue.
 
 ## Troubleshooting steps
 
-1. View the `ClusterResourcePlacement` status and locate the `placementStatuses` section. Check the `placementStatuses` value to identify which clusters have the `ResourceApplied` condition set to `False`, and note their `clusterName` value.
-2. Locate the `Work` object in the hub cluster. Use the identified `clusterName` to locate the `Work` object that's associated with the member cluster. For more information, see [How to find the correct Work resource associated with `ClusterResourcePlacement`](troubleshoot-clusterresourceplacement-api-issues.md#find-work).
-3. Check the status of the `Work` object to understand the specific issues that are preventing successful resource application.
+1. To identify clusters with the `ClusterResourcePlacementApplied` (for ClusterResourcePlacement) or `ResourcePlacementApplied` (for ResourcePlacement) condition set to `False`, inspect the `placementStatuses` in the placement status section and note down their `clusterName`.
+2. To locate the `Work` object associated with the member cluster, use the identified `clusterName`.
+   - For ClusterResourcePlacement, see [How to find the correct Work resource associated with `ClusterResourcePlacement`](troubleshoot-clusterresourceplacement-api-issues.md#find-work)
+   - For ResourcePlacement, see [How to find the correct Work resource associated with `ResourcePlacement`](troubleshoot-resource-placement-issues.md#find-work)
+3. To understand the specific issues preventing successful resource application, inspect the status of the `Work` object.
 
-## Case study
+## Case study: ClusterResourcePlacement
 
-In the following example, `ClusterResourcePlacement` is trying to propagate a namespace that contains a deployment to two member clusters. However, the namespace already exists on one member cluster, specifically `kind-cluster-1`.
+In the following example, a `ClusterResourcePlacement` is trying to propagate a namespace that contains a deployment to two member clusters. However, the namespace already exists on one member cluster, specifically `kind-cluster-1`.
 
 ### ClusterResourcePlacement specifications
 
@@ -191,7 +227,7 @@ status:
     version: v1
 ```
 
-In the `failedPlacements` section for `kind-cluster-1`, the `message` fields explain why the resource wasn't applied on the member cluster. In the preceding `conditions` section, the `Applied` condition for `kind-cluster-1` is flagged as `false` and shows the `NotAllWorkHaveBeenApplied` reason. This indicates that the `Work` object that's intended for the member cluster `kind-cluster-1` wasn't applied. For more information, see [How to find the correct Work resource associated with `ClusterResourcePlacement`](troubleshoot-clusterresourceplacement-api-issues.md#find-work).
+In the `failedPlacements` section for `kind-cluster-1`, the `message` fields explain why the resource wasn't applied on the member cluster. In the preceding `conditions` section, the `Applied` condition for `kind-cluster-1` is flagged as `false` and shows the `NotAllWorkHaveBeenApplied` reason. The `Work` object intended for the member cluster `kind-cluster-1` wasn't applied. For more information, see [How to find the correct Work resource associated with `ClusterResourcePlacement`](troubleshoot-clusterresourceplacement-api-issues.md#find-work).
 
 ### Work status of kind-cluster-1
 
@@ -258,8 +294,19 @@ Check the `Work` status, particularly the `manifestConditions` section. You can
 
 ### Resolution
 
-In this situation, a potential solution is to set the `AllowCoOwnership` to `true` in the ApplyStrategy policy. However, it's important to notice that this decision should be made by the user because the resources might not be shared.
+In the situation, set the `AllowCoOwnership` to `true` in the ApplyStrategy policy. However, the user must make the decision because the resources might not be shared.
+
+## General troubleshooting notes
+
+The troubleshooting process and Work object inspection are identical for both placement types:
+
+- Both use the same underlying Work API to apply resources to member clusters.
+- The Work object status and manifestConditions have the same structure regardless of the placement type that created them.
+- The main difference is the scope: the cluster-scoped placement can select both cluster-scoped and namespace-scoped resources, while the namespace-scoped placement can only select namespace-scoped resources within its own namespace.
+
+For ResourcePlacement-specific considerations:
 
-Additionally, you can review the logs for the [Apply Work Controller](https://github.com/Azure/fleet/blob/main/pkg/controllers/work/apply_controller.go) for more insights into why the resources are unavailable.
+- Ensure the target namespace exists on member clusters before the ResourcePlacement tries to apply resources to it
+- ResourcePlacement can only select resources within the same namespace where the ResourcePlacement object itself resides
 
 

support/azure/kubernetes-fleet/cluster-resource-placement/crp-clusterresourceplacementavailable-false.md

@@ -1,30 +1,66 @@
 ---
-title: ClusterResourcePlacementAvailable is false when using ClusterResourcePlacement API object in Azure Kubernetes Fleet Manager
-description: Helps you resolve ClusterResourcePlacementAvailable failure when you propagate resources by using the ClusterResourcePlacement API object in Azure Kubernetes Fleet Manager APIs.
-ms.date: 08/05/2024
+title: PlacementAvailable failure when using placement APIs in Azure Kubernetes Fleet Manager
+description: Helps you resolve ClusterResourcePlacementAvailable or ResourcePlacementAvailable failure when you propagate resources by using the ClusterResourcePlacement or ResourcePlacement API object in Azure Kubernetes Fleet Manager APIs.
+ms.date: 12/09/2025
 ms.reviewer: zhangryan, chiragpa, shasb, ericlucier, arfallas, sachidesai
 ms.service: azure-kubernetes-fleet-manager
 ms.custom: sap:Other issue or questions related to Fleet manager
 ---
 
-# Resource propagation failure: ClusterResourcePlacementAvailable is False
+# Resource propagation failure: PlacementAvailable is False
 
-This article discusses how to troubleshoot `ClusterResourcePlacementAvailable` issues when you propagate resources by using the `ClusterResourcePlacement` object API in Microsoft Azure Kubernetes Fleet Manager.
+## Summary
+
+This article discusses how to troubleshoot resource availability failures when you propagate resources by using placement APIs in Microsoft Azure Kubernetes Fleet Manager. This issue applies to both `ClusterResourcePlacement` and `ResourcePlacement`, each with their own dedicated custom resource condition types:
+
+- `ClusterResourcePlacementAvailable` for ClusterResourcePlacement
+- `ResourcePlacementAvailable` for ResourcePlacement
+
+Sample error messages:
+
+# [ClusterResourcePlacement](#tab/clusterresourceplacement)
+
+```yaml
+  - lastTransitionTime: "2024-05-07T23:32:40Z"
+    message: Failed to check the availability of resources in 1 clusters, please check the `failedPlacements` status
+    observedGeneration: 1
+    reason: ResourcesUnavailable
+    status: "False"
+    type: ClusterResourcePlacementAvailable
+```
+
+# [ResourcePlacement](#tab/resourceplacement)
+
+```yaml
+  - lastTransitionTime: "2024-05-07T23:32:40Z"
+    message: Failed to check the availability of resources in 1 clusters, please check the `failedPlacements` status
+    observedGeneration: 1
+    reason: ResourcesUnavailable
+    status: "False"
+    type: ResourcePlacementAvailable
+```
+
+---
 
 ## Symptoms
 
-When you use the `ClusterResourcePlacement` API object in Azure Kubernetes Fleet Manager to propagate resources, the deployment fails. The `ClusterResourcePlacementAvailable` status shows as `False`.
+When you use the `ClusterResourcePlacement` or `ResourcePlacement` API object in Azure Kubernetes Fleet Manager to propagate resources, the deployment fails. The `ClusterResourcePlacementAvailable` (for ClusterResourcePlacement) or `ResourcePlacementAvailable` (for ResourcePlacement) status shows as `False`.
+
+> [!NOTE]
+> To get more information about why resources are unavailable, check the work applier controller logs. Detailed failures are placed in the `failedPlacements` section of the placement status. For more information about viewing Fleet agent logs, see [View agent logs in Azure Kubernetes Fleet Manager](/azure/kubernetes-fleet/view-fleet-agent-logs).
 
 ## Cause
 
 This issue might occur because of one of the following reasons:
 
 - The member cluster doesn't have enough resource availability.
 - The deployment contains an invalid image name.
+- Required resources (such as persistent volumes, config maps, or secrets) are missing.
+- Resource quotas or limit ranges are preventing the resource from becoming available.
 
-## Case study
+## Case study: ClusterResourcePlacement
 
-The following example shows that `ClusterResourcePlacement` doesn't propagate a deployment to a member cluster because of an invalid image name.
+The following example shows that a `ClusterResourcePlacement` is unable to propagate a deployment to a member cluster because of an invalid image name.
 
 #### ClusterResourcePlacement specifications
 
@@ -153,7 +189,7 @@ status:
     namespace: test-ns
     version: v1
  ```
-In the `failedPlacements` section for `kind-cluster-1`, the `message` field explains why the resource wasn't applied on the member cluster. In the preceding `conditions` section, the `Applied` condition for `kind-cluster-1` is flagged as `false` and shows the `NotAllWorkHaveBeenApplied` reason. This indicates that the `Work` object that's intended for the member cluster `kind-cluster-1` wasn't applied. For more information, see [How to find the correct Work resource associated with `ClusterResourcePlacement`](troubleshoot-clusterresourceplacement-api-issues.md#find-work).
+In the `failedPlacements` section for `kind-cluster-1`, the `message` field explains why the resource wasn't applied on the member cluster. In the preceding `conditions` section, the `Applied` condition for `kind-cluster-1` is flagged as `false` and shows the `NotAllWorkHaveBeenApplied` reason. The `Work` object intended for the member cluster `kind-cluster-1` wasn't applied. For more information, see [How to find the correct Work resource associated with `ClusterResourcePlacement`](troubleshoot-clusterresourceplacement-api-issues.md#find-work).
 
 ### Work status of kind-cluster-1
 ```
@@ -213,13 +249,20 @@ conditions:
     version: v1
 ```
 
-Check the `Available` status for `kind-cluster-1`. You can see that the `my-deployment` deployment isn't yet available on the member cluster. This suggests that an issue might be affecting the deployment manifest.
+Check the `Available` status for `kind-cluster-1`. You can see that the `my-deployment` deployment isn't yet available on the member cluster. An issue might be affecting the deployment manifest.
 
 ### Resolution
 
-In this situation, a potential solution is to check the deployment in the member cluster because the message indicates that the root cause of the issue is a bad image name. After this image name is identified, you can correct the deployment manifest and update it. After you fix and update the resource manifest, the `ClusterResourcePlacement` object API automatically propagates the corrected resource to the member cluster.
+In the situation, check the deployment in the member cluster because the message indicates that the root cause of the issue is a bad image name. After you identify the image name, correct the deployment manifest and update it. After you fix and update the resource manifest, the placement object (ClusterResourcePlacement or ResourcePlacement) automatically propagates the corrected resource to the member cluster.
 
 For all other situations, make sure that the propagated resource is configured correctly. Additionally, verify that the selected cluster has sufficient available capacity to accommodate the new resources.
 
- 
+## General troubleshooting notes
+
+The troubleshooting process and Work object inspection are identical for both placement types:
+
+- Both use the same underlying Work API to apply resources to member clusters.
+- The Work object status and manifestConditions have the same structure regardless of the placement type that created them.
+- The `Available` condition in the Work status indicates whether the applied resources are now available on the member cluster.
+- The main difference is the scope: the cluster-scoped placement can select both cluster-scoped and namespace-scoped resources, while the namespace-scoped placement can only select namespace-scoped resources within its own namespace.