AKS cluster auto-upgrade did not execute during scheduled maintenance window

az aks maintenanceconfiguration list --resource-group rg-infra-r-westus3-tst --cluster-name clu-r-usw3-tst
[
  {
    "id": "/subscriptions/2e165671-918f-427f-8e13-3ec8e39812e6/resourceGroups/rg-infra-r-westus3-tst/providers/Microsoft.ContainerService/managedClusters/clu-r-usw3-tst/maintenanceConfigurations/aksManagedAutoUpgradeSchedule",
    "maintenanceWindow": {
      "durationHours": 24,
      "notAllowedDates": null,
      "schedule": {
        "absoluteMonthly": null,
        "daily": null,
        "relativeMonthly": {
          "dayOfWeek": "Saturday",
          "intervalMonths": 1,
          "weekIndex": "Last"
        },
        "weekly": null
      },
      "startDate": "2026-06-18",
      "startTime": "04:00",
      "utcOffset": "+00:00"
    },
    "name": "aksManagedAutoUpgradeSchedule",
    "notAllowedTime": null,
    "resourceGroup": "rg-infra-r-westus3-tst",
    "systemData": null,
    "timeInWeek": null,
    "type": null
  },
  {
    "id": "/subscriptions/2e165671-918f-427f-8e13-3ec8e39812e6/resourceGroups/rg-infra-r-westus3-tst/providers/Microsoft.ContainerService/managedClusters/clu-r-usw3-tst/maintenanceConfigurations/aksManagedNodeOSUpgradeSchedule",
    "maintenanceWindow": {
      "durationHours": 24,
      "notAllowedDates": null,
      "schedule": {
        "absoluteMonthly": null,
        "daily": null,
        "relativeMonthly": null,
        "weekly": {
          "dayOfWeek": "Saturday",
          "intervalWeeks": 1
        }
      },
      "startDate": "2026-06-18",
      "startTime": "04:00",
      "utcOffset": "+00:00"
    },
    "name": "aksManagedNodeOSUpgradeSchedule",
    "notAllowedTime": null,
    "resourceGroup": "rg-infra-r-westus3-tst",
    "systemData": null,
    "timeInWeek": null,
    "type": null
  }
]

Hey Ying — I can see why this is confusing. With AKS planned maintenance + Stable auto-upgrade, you’d expect an automatic Kubernetes version upgrade to happen inside the scheduled window, but AKS will only start an upgrade when it’s eligible and when the upgrade type is actually governed by the maintenance configuration that matches that upgrade.

Based on the guidance in the provided docs, here are the most likely reasons an upgrade didn’t trigger, plus the checks you (or the customer) can run to confirm.

1) Planned maintenance window doesn’t guarantee an upgrade will happen every time

AKS will treat the maintenance window as when it’s allowed to perform upgrades, but it does not guarantee it will perform one during each window. An upgrade is initiated only if:

• there is an eligible target Kubernetes version available for the selected auto-upgrade channel (Stable)
• and the upgrade prerequisites are satisfied

So the cluster could remain at 1.33.7 if no newer eligible version was available/eligible during that window.

Check what upgrades were available

Run (you already did this for other clusters too):

az aks get-upgrades --resource-group <rg-name> --name <cluster-name>

Compare the upgrade targets returned for:

• clu-r-usw3-tst (non-upgraded)
• a working cluster (like clu-r-yt-tst)

2) The maintenance configuration name that controls Kubernetes auto-upgrade may not be applied

For AKS cluster (Kubernetes) version auto-upgrades, the maintenance configuration that controls it needs to be named exactly:

• aksManagedAutoUpgradeSchedule

The docs also call out that default is used for AKS weekly platform releases / platform maintenance activities and does not gate Kubernetes auto-upgrades the way aksManagedAutoUpgradeSchedule does.

Verify maintenance configurations actually configured on the cluster

Check what maintenance configurations exist on clu-r-usw3-tst:

az aks maintenanceconfiguration list --resource-group <NAME> --cluster-name <NAME>

Also, from the AKS planned maintenance FAQ:

• it’s possible to have the maintenance windows present, but not applied to the specific upgrade type the way you expect

If your maintenance setup is only associated with default (or otherwise missing/incorrect for Kubernetes version upgrades), AKS may not evaluate/execute cluster auto-upgrade during that scheduled time.

3) Cluster state / timing issues

Planned maintenance won’t perform upgrades if the cluster isn’t in a running state when the window starts.

Confirm the cluster is running

az aks show --resource-group <rg-name> --name <cluster-name> --query powerState

Also, AKS needs time to factor in maintenance changes; docs recommend ensuring at least 15 minutes between maintenance configuration update and the scheduled start time.

4) Upgrade prerequisites blocking the upgrade (PDBs, drain/surge constraints, node pool issues)

Even if AKS attempts to start an upgrade, it can be blocked by conditions that prevent node drain/evictions.

Check Pod Disruption Budgets

kubectl get pdb --all-namespaces

If PDBs are too restrictive (or similar constraints exist), the upgrade may not progress until an eligible window where it can drain nodes successfully.

5) There may have been no upgrade attempt (so you should validate via Activity Logs)

Since you said you don’t see upgrade logs from your side, you want to confirm whether AKS ever initiated an upgrade evaluation/operation around the expected window.

Pull upgrade-related Activity Log events

Use an activity log query similar to the doc guidance (filter for upgrade operations). Example:

az monitor activity-log list \

  --resource-group <rg-name> \

  --namespace Microsoft.ContainerService

And/or (as suggested in the planned maintenance docs):

az monitor activity-log list --resource-group myResourceGroup \

--namespace Microsoft.ContainerService --output json \

--query "[?contains(operationName.value, 'UPGRADE')]"

Then share the results from the time range covering:

• just before 2026-05-30 04:00 UTC
• through after the window closes

What I’d ask you to confirm next (to pinpoint root cause fast)

1. Output of:

az aks maintenanceconfiguration list --resource-group <rg> --cluster-name clu-r-usw3-tst

2. Output of:

az aks show --resource-group <rg> --name clu-r-usw3-tst --query powerState

3. Output of:

az aks get-upgrades --resource-group <rg> --name clu-r-usw3-tst

(especially showing whether any target version exists that would be eligible during that window)

4. Any UPGRADE-related Activity Log entries from around the expected maintenance window.

Reference (all provided)

• AKS Auto Upgrade: https://learn.microsoft.com/azure/aks/auto-upgrade-cluster
• AKS Planned Maintenance (FAQ + troubleshooting): https://learn.microsoft.com/azure/aks/planned-maintenance
• Planned maintenance with cluster auto-upgrade: https://learn.microsoft.com/azure/aks/planned-maintenance#using-planned-maintenance-with-cluster-auto-upgrade
• Planned maintenance (list/create configuration): https://learn.microsoft.com/azure/aks/planned-maintenance#create-a-maintenance-window
• AKS Auto-upgrade channel overview: https://supportabilityhub.microsoft.com/solutions/apollosolutions/3030e216-e16e-c667-9a33-9d1be5eb93f9/55682304-3f5c-4c75-b8a1-8e58892dafeb
• Prevent AKS clusters from auto-upgrading (planned maintenance behavior): https://supportabilityhub.microsoft.com/solutions/apollosolutions/3030e216-e16e-c667-9a33-9d1be5eb93f9/8bf80278-6b7c-47a7-b788-b934f6edeccc
• Planned maintenance configuration troubleshooting compendium: https://supportabilityhub.microsoft.com/solutions/apollosolutions/3030e216-e16e-c667-9a33-9d1be5eb93f9/1c833df4-a7a0-4f61-b635-48834e78e8cc
• Monitor AKS (general reference used for Activity Logs): https://learn.microsoft.com/azure/aks/monitor-aks
• Example of “How can I check what triggered my cluster upgrade?” (Activity Log filter guidance): https://learn.microsoft.com/azure/aks/upgrade-aks-cluster#upgrade-an-aks-cluster (referenced via planned maintenance troubleshooting content)

If you paste the maintenanceconfiguration list + the activity log upgrade-filter output for the May 30 window, we can usually tell whether it’s (a) missing/incorrect aksManagedAutoUpgradeSchedule association, (b) no eligible version available, or (c) a blocking prerequisite like PDB/drain.

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.