Skip to main content

How to Fix AKS Cluster Auto-Upgrade Not Executing During Scheduled Maintenance Window

How to Fix AKS Cluster Auto-Upgrade Not Executing During Scheduled Maintenance Window

Your AKS cluster is configured with Stable auto-upgrade and a scheduled maintenance window — but the upgrade window passed and the cluster version has not changed. No error. No log entry. Just silence. This guide covers all seven reasons an AKS auto-upgrade is silently skipped, with step-by-step diagnostics and fixes for each.

7 reasons
An AKS auto-upgrade can silently skip a maintenance window with no error or log entry — seven known causes
#1 cause
startDate set to a future date — the maintenance window is valid but not yet active; AKS skips silently
Best effort
Microsoft documentation explicitly states maintenance windows are best-effort, not guaranteed to run every cycle
4 hours min
The minimum recommended duration for aksManagedAutoUpgradeSchedule — windows shorter than 4 hours often fail to complete

How AKS Auto-Upgrade and Maintenance Windows Actually Work

Before diagnosing why the upgrade did not run, it is important to understand what "scheduled maintenance window" means in AKS — because the mental model most engineers carry is incorrect. A maintenance window in AKS defines a time range during which AKS is permitted to run an upgrade. It does not guarantee that an upgrade will run during every occurrence of that window. Microsoft's documentation states explicitly: maintenance operations are considered best-effort only and are not guaranteed to occur within a specified window.

For an auto-upgrade to actually execute during a maintenance window, all of the following conditions must be true simultaneously:

  • The maintenance configuration must be named exactly aksManagedAutoUpgradeSchedule
  • The window's startDate must be in the past (the window is active)
  • The window duration must be at least 4 hours
  • There must be an eligible target Kubernetes version available on the selected upgrade channel
  • The cluster must be in a Running (non-stopped) state
  • No blocking pre-upgrade validations must be failing (PDB, subnet IPs, quota, API deprecations)
  • No Azure regional capacity or resource lock is preventing surge node provisioning

If any one of these conditions is not met, AKS silently skips the upgrade window with no error message and no Activity Log entry. This silent skip behaviour is the primary reason engineers are confused — they see no evidence of an attempted upgrade because no attempt was made.

Figure 1 — AKS auto-upgrade decision chain: all gates must pass for an upgrade to execute
Config nameaksManagedAutoUpgradeSchedulestartDatemust be inthe pastDuration≥ 4 hoursrecommendedEligibleversion existson channelPre-upgradevalidationspass (PDB etc)Cluster runningcapacity / quotaavailable✓ Upgrade executes during maintenance windowANY GATE FAILS = SILENT SKIP — No error message. No Activity Log entry.If ANY of the six gates above is not satisfied, AKS skips the upgrade for this window cycleand waits until the next scheduled occurrence. There is no notification, no warning, no alert.This is by design — maintenance windows are best-effort, not guaranteed.Gate 1Gate 2Gate 3Gate 4Gate 5Gate 6
Every gate must pass. One silent failure at any stage means zero log entries and no upgrade — making the diagnosis entirely dependent on manually checking each gate's configuration.

Immediate Diagnosis — Run These Commands First

Run all of these before diving into the individual causes. The outputs together tell you which gate failed. Save all outputs — you will need them if you open a support ticket.

Azure CLI — Complete diagnostic snapshot (run all at once, save all output)RG="rg-infra-r-westus3-tst"
CLUSTER="clu-r-usw3-tst"

# 1. Current cluster state and version echo "=== CLUSTER STATE ==="
az aks show \
  --resource-group "${RG}" --name "${CLUSTER}" \
  --query "{Version:kubernetesVersion,UpgradeChannel:autoUpgradeProfile.upgradeChannel,PowerState:powerState.code,ProvisioningState:provisioningState}" \
  --output json

# 2. ALL maintenance configurations — check names and startDates echo "=== MAINTENANCE CONFIGURATIONS ==="
az aks maintenanceconfiguration list \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --output json

# 3. Available upgrades on the Stable channel echo "=== AVAILABLE UPGRADES ==="
az aks get-upgrades \
  --resource-group "${RG}" --name "${CLUSTER}" \
  --output table

# 4. Node pool status and versions echo "=== NODE POOLS ==="
az aks nodepool list \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --query "[].{Name:name,Version:orchestratorVersion,State:provisioningState,Count:count,MaxSurge:upgradeSettings.maxSurge}" \
  --output table

# 5. Resource locks echo "=== RESOURCE LOCKS ==="
az resource lock list \
  --resource-group "${RG}" \
  --output table

# 6. Activity log around the missed maintenance window (May 30) echo "=== ACTIVITY LOG (May 28–June 1) ==="
RESOURCE_ID=$(az aks show --resource-group "${RG}" --name "${CLUSTER}" --query id -o tsv)
az monitor activity-log list \
  --resource-id "${RESOURCE_ID}" \
  --start-time 2026-05-28T00:00:00Z \
  --end-time 2026-06-01T00:00:00Z \
  --query "[].{Time:eventTimestamp,Operation:operationName.value,Status:status.value,Caller:caller}" \
  --output table
ℹ The Most Important Thing to Check First

In the maintenance configuration output from command #2, look at the startDate field of the aksManagedAutoUpgradeSchedule configuration. If this date is after the expected maintenance window (e.g. June 18 when the expected window was May 30), the window was not yet active when it should have run. This is the most common cause of a silent skip and is completely silent — no error, no log, no warning.

The Seven Causes

Cause 1 — startDate Is Set to a Future Date (Most Common)

This is the confirmed root cause for the cluster described in this post. The maintenance configuration output showed "startDate": "2026-06-18" while the expected upgrade window was May 30, 2026. Because the startDate was 19 days in the future at the time of the expected window, AKS had not yet begun honouring the maintenance schedule. The window technically exists but has not become active.

The startDate is the date from which AKS begins evaluating the maintenance schedule. Before this date, no maintenance window occurrences are recognised and no upgrades are triggered. This is a silent condition — there is no warning, no alert, and no Activity Log entry when a window is skipped because the startDate has not been reached.

Azure CLI — Diagnose and fix: startDate in the future# Diagnose: check the startDate az aks maintenanceconfiguration show \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --name aksManagedAutoUpgradeSchedule \
  --query "maintenanceWindow.startDate"
# If output is a future date (after today), this is the cause

# Fix: update startDate to today or a recent past date # This activates the maintenance schedule immediately az aks maintenanceconfiguration update \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --name aksManagedAutoUpgradeSchedule \
  --config-file - <<EOF
{
  "properties": {
    "maintenanceWindow": {
      "schedule": {
        "relativeMonthly": {
          "dayOfWeek": "Saturday",
          "intervalMonths": 1,
          "weekIndex": "Last"
        }
      },
      "durationHours": 24,
      "startDate": "2026-06-01",
      "startTime": "04:00",
      "utcOffset": "+00:00"
    }
  }
}
EOF

# Verify the update az aks maintenanceconfiguration show \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --name aksManagedAutoUpgradeSchedule \
  --query "maintenanceWindow.startDate"

Cause 2 — Wrong Configuration Name (Not aksManagedAutoUpgradeSchedule)

AKS has three reserved maintenance configuration names, each controlling a different type of update. Only aksManagedAutoUpgradeSchedule gates Kubernetes version auto-upgrades. A configuration named default controls only AKS weekly platform releases — it has no effect on cluster version auto-upgrades. Any other name (including custom names like my-upgrade-schedule or simply maintenance) is completely ignored by the auto-upgrade system.

⚠ The Three Reserved Names — Using Any Other Name Does Nothing

default — controls AKS weekly platform releases only (control plane components, system add-ons). Has no effect on Kubernetes version auto-upgrades.

aksManagedAutoUpgradeSchedule — controls when Kubernetes version auto-upgrades run. This is what you need for Stable/Rapid/Patch channel upgrades.

aksManagedNodeOSUpgradeSchedule — controls when node OS security patch upgrades run. Separate from the Kubernetes version upgrade schedule.

If your configuration has any other name, AKS will never use it for auto-upgrades. You must delete it and recreate it with the exact name aksManagedAutoUpgradeSchedule.

Azure CLI — Check configuration name and fix if wrong# Check all configuration names az aks maintenanceconfiguration list \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --query "[].name" --output table
# Expected: aksManagedAutoUpgradeSchedule should appear in the list
# If only "default" appears, you need to create the correct configuration

# Fix: create the correct aksManagedAutoUpgradeSchedule configuration # (if the wrong name was used, delete the old one first) az aks maintenanceconfiguration add \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --name aksManagedAutoUpgradeSchedule \
  --schedule-type RelativeMonthly \
  --day-of-week Saturday \
  --week-index Last \
  --interval-months 1 \
  --start-time "04:00" \
  --duration 24 \
  --utc-offset +00:00 \
  --start-date "2026-07-01" # Set to today or recent past

Cause 3 — No Eligible Version Available on the Stable Channel

The most common legitimate reason for a skipped window. AKS's Stable auto-upgrade channel upgrades to the latest patch version of Kubernetes N-1 — the second-most-recent minor version. If your cluster is already on the highest available patch of the Stable channel target, there is nothing to upgrade to and the window is silently skipped.

This can happen if: the Stable channel has not yet published a new version since your last upgrade; your cluster is already on 1.33.x and Stable is targeting 1.33.x as N-1 with no higher patch available; or the new Stable version is still rolling out to West US 3 and has not reached your region yet (AKS releases take up to two weeks to reach all regions via safe deployment practices).

Azure CLI — Check what versions are available for upgrade# Check available upgrades — if empty or shows current version, nothing to upgrade to az aks get-upgrades \
  --resource-group "${RG}" --name "${CLUSTER}" \
  --output json

# Check all supported Kubernetes versions in West US 3 az aks get-versions --location westus3 --output table

# The Stable channel targets: GA versions that are at least one minor version older # than the latest available. If cluster is on 1.33.7 and Stable targets 1.33.x # with 1.33.7 being the latest patch — no upgrade exists yet.

# Check AKS weekly release tracker for West US 3: # https://releases.aks.azure.com/webpage/index.html

Cause 4 — Maintenance Window Duration Too Short (Less Than 4 Hours)

Microsoft requires a minimum of 4 hours for an aksManagedAutoUpgradeSchedule window to function reliably. A window shorter than 4 hours may not provide enough time for the control plane upgrade and all node pool upgrades to complete. AKS will not start an upgrade operation that cannot complete within the remaining window time — if the window is too short to complete the upgrade, AKS may skip the window entirely rather than start a partial upgrade.

For large clusters with multiple node pools or many nodes, consider 8–12 hours. The cluster in this post has durationHours: 24, so this is not the cause here — but it is a frequent misconfiguration on smaller maintenance windows.

Azure CLI — Check and fix window duration# Check current duration az aks maintenanceconfiguration show \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --name aksManagedAutoUpgradeSchedule \
  --query "maintenanceWindow.durationHours"
# Minimum recommended: 4 hours. For production clusters: 8–12 hours.

# Fix: update duration to at least 4 hours az aks maintenanceconfiguration update \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --name aksManagedAutoUpgradeSchedule \
  --duration 8

Cause 5 — PDB or Node Pool Blocking Conditions

AKS performs pre-upgrade validations before starting an upgrade. If any validation fails, the upgrade is not initiated. Key validations include checking for Pod Disruption Budgets with maxUnavailable=0 or minAvailable equal to the total replica count (leaving no room for drain), deprecated API usage in workloads, subnet IP exhaustion (insufficient IPs for surge nodes), expired certificates or service principals, and resource locks on the managed cluster resource group.

A PDB that sets maxUnavailable: 0 means no pod in that deployment can be evicted during a node drain — making it impossible for AKS to drain any node. This completely blocks the upgrade without any node being touched. The pre-upgrade validation catches this before the upgrade starts, so it looks exactly like a skipped window from the outside.

kubectl + Azure CLI — Check PDBs and pre-upgrade blocking conditions# Check all PDBs across all namespaces kubectl get pdb --all-namespaces -o wide
# Look for PDBs where ALLOWED DISRUPTIONS = 0 and MIN AVAILABLE = DESIRED (blocking)

# Check for misconfigured PDBs (maxUnavailable=0) kubectl get pdb --all-namespaces -o json | \
  jq '.items[] | select(.spec.maxUnavailable==0 or .status.disruptionsAllowed==0) | {name:.metadata.name,namespace:.metadata.namespace,maxUnavailable:.spec.maxUnavailable,disruptionsAllowed:.status.disruptionsAllowed}'

# Check for deprecated API usage (blocks upgrades to versions that remove the API) kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

# Check subnet available IPs (need IPs for surge nodes) az aks show --resource-group "${RG}" --name "${CLUSTER}" \
  --query "agentPoolProfiles[].{Name:name,VnetSubnetID:vnetSubnetId,Count:count,MaxSurge:upgradeSettings.maxSurge}" \
  --output table

# Check for resource locks on the managed resource group INFRA_RG=$(az aks show --resource-group "${RG}" --name "${CLUSTER}" --query nodeResourceGroup -o tsv)
az resource lock list --resource-group "${INFRA_RG}" --output table
Figure 2 — How a misconfigured PDB silently blocks an AKS upgrade before it starts
AKS Pre-UpgradeValidation EngineRuns before any nodeor pod is touchedChecks performed:✓ PDB allows disruption✓ No deprecated APIs in use✓ Sufficient subnet IPs✓ Valid upgrade path✓ Certs/SP not expired✓ No resource locks✓ Quota for surge nodes✓ Cluster in Running stateAll pass→ Upgrade startsAny check fails→ Upgrade silently skippedNo error. No Activity Log.No nodes touched.
A blocking PDB looks identical to "no eligible version" from the outside — both produce zero Activity Log entries. Pre-upgrade validation catches PDB issues before the upgrade starts.

Cause 6 — Regional Capacity or Quota Constraint

AKS upgrades use max surge to provision temporary extra nodes during the rolling update. If your subscription does not have sufficient vCPU quota in the West US 3 region, or if the region does not have capacity for the node VM size at the time of the upgrade window, the upgrade cannot provision surge nodes and will fail the pre-upgrade validation. Errors that appear in the Activity Log (when an upgrade does attempt) include SKUNotAvailable, AllocationFailed, or OverconstrainedAllocationRequest.

For specialised VM sizes (GPU nodes, high-memory nodes), regional capacity is more constrained than for general-purpose sizes. Check whether your subscription quota in West US 3 is sufficient for the current node count plus the max surge count.

Azure CLI — Check quota and max surge settings# Check current vCPU quota in West US 3 az vm list-usage --location westus3 \
  --query "[?contains(name.value, 'cores')].{Name:name.localizedValue,Used:currentValue,Limit:limit}" \
  --output table

# Check node pool max surge settings (default is 1 — very conservative) az aks nodepool list \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --query "[].{Pool:name,Count:count,SKU:vmSize,MaxSurge:upgradeSettings.maxSurge}" \
  --output table

# Recommended: set max surge to 33% for production, or at minimum 1 az aks nodepool update \
  --resource-group "${RG}" --cluster-name "${CLUSTER}" \
  --name nodepool1 \
  --max-surge "33%"

Cause 7 — Cluster Not in Running State During Window

Auto-upgrades only execute when the cluster is in a Running power state. If the cluster was stopped (deallocated) when the maintenance window ran, the upgrade is skipped. Similarly, if the cluster was in a Failed provisioning state from a previous operation, upgrade and scale operations will not be accepted.

Azure CLI — Check cluster power and provisioning state# Check current power state and provisioning state az aks show \
  --resource-group "${RG}" --name "${CLUSTER}" \
  --query "{PowerState:powerState.code,ProvisioningState:provisioningState}" \
  --output json
# Expected for upgrades: powerState=Running, provisioningState=Succeeded
# If powerState=Stopped: start the cluster first
# If provisioningState=Failed: resolve the failed state before expecting auto-upgrade

How to Find Auto-Upgrade Activity Logs

A key frustration with AKS auto-upgrade is that when it is silently skipped, there is genuinely nothing to find in the Activity Log — no skipped-upgrade event is recorded. Activity Log entries only exist when an upgrade was attempted. The absence of log entries is itself the diagnostic signal for a silent skip.

When an upgrade does attempt and either succeeds or fails, the Activity Log entries to look for are:

  • Create or Update Managed Cluster — triggered when the cluster control plane upgrade starts
  • Create or Update Agent Pool — triggered when a node pool upgrade starts
  • Upgrade Agent Pool Image Version — for node OS image upgrades specifically

All of these should show Caller as a Microsoft/AKS service identity rather than your user account — this distinguishes auto-upgrades from manually triggered upgrades.

Azure CLI — Search Activity Log for upgrade events and AKS-initiated operationsRESOURCE_ID=$(az aks show --resource-group "${RG}" --name "${CLUSTER}" --query id -o tsv)

# Search for upgrade-related operations in the last 90 days az monitor activity-log list \
  --resource-id "${RESOURCE_ID}" \
  --start-time 2026-05-01T00:00:00Z \
  --query "[?contains(operationName.value, 'upgrade') || contains(operationName.value, 'Upgrade')].{Time:eventTimestamp,Op:operationName.value,Status:status.value,Caller:caller}" \
  --output table

# Search for ALL operations around the maintenance window (May 28–Jun 1) az monitor activity-log list \
  --resource-id "${RESOURCE_ID}" \
  --start-time 2026-05-28T00:00:00Z \
  --end-time 2026-06-01T00:00:00Z \
  --query "[].{Time:eventTimestamp,Op:operationName.value,Status:status.value,Caller:caller}" \
  --output table

# If nothing appears for upgrade operations during the expected window: # The upgrade was silently skipped — not attempted at all. # Check causes 1-7 above to identify which gate failed.

# For richer upgrade event detail, check Container Insights if enabled: # kubectl get events --field-selector source=upgrader --all-namespaces # (only shows current events unless Container Insights is sending to Log Analytics)
Figure 3 — Complete troubleshooting decision tree: mapping the silent skip to its cause
Auto-upgrade skipped — no Activity Log entriesIs the configuration named aksManagedAutoUpgradeSchedule?NOCause 2Wrong nameYESIs startDate in the past?NOCause 1 ← #1Future startDateYESIs there an eligible upgrade version?NO — expectedCause 3 — OKNo version yetYESDo PDB / pre-upgrade validations pass?NOCause 5PDB / validation blockYESIs quota / capacity available for surge nodes?NOCause 6Quota/capacityYES✓ Upgrade should execute — check Cause 4 (duration) and Cause 7 (cluster state)
Work top-down through this tree. Cause 1 (future startDate) and Cause 2 (wrong name) account for the majority of silent skip cases and are the fastest to check and fix.

Set Up Monitoring So You Always Know When Upgrades Run

Because a skipped auto-upgrade produces no log entries, you need proactive monitoring to know whether upgrades are running. The best approach is a combination of version comparison alerts and Activity Log alerts for upgrade operations.

Monitor SignalWhat It Tells YouHow to Set It Up
Activity Log alert on Create or Update Managed ClusterFires whenever AKS starts a cluster-level operation — including auto-upgrades. Confirms the upgrade was attempted, not just scheduled.Portal → Cluster → Alerts → Create alert rule → Signal: Activity Log → Create or Update Managed Cluster
Kubernetes version metric tracked in Log AnalyticsTracks cluster version over time. A version that has not changed after expected maintenance windows indicates a silent skip pattern.Enable Container Insights → query KubeNodeInventory | summarize by ClusterVersion on a weekly schedule
kubectl events from upgraderShows drain, surge, and PDB eviction events during an active upgrade. The key source is source=upgrader.kubectl get events --field-selector source=upgrader -A during or after a maintenance window
Storage of Activity Log to Log AnalyticsExtends Activity Log retention beyond 90 days. Enables KQL queries for upgrade history and audit evidence.Diagnostic settings on the subscription → Send to Log Analytics Workspace → Category: Administrative
Azure CLI — Create an alert for AKS upgrade events# Create action group for email notifications az monitor action-group create \
  --resource-group "${RG}" \
  --name "aks-upgrade-alerts" \
  --short-name "aksupgrade" \
  --action email platform-team "platform@yourcompany.com"

AG_ID=$(az monitor action-group show --resource-group "${RG}" --name "aks-upgrade-alerts" --query id -o tsv)
RESOURCE_ID=$(az aks show --resource-group "${RG}" --name "${CLUSTER}" --query id -o tsv)

# Alert when an upgrade operation starts on this cluster az monitor activity-log alert create \
  --name "aks-upgrade-started" \
  --resource-group "${RG}" \
  --scope "${RESOURCE_ID}" \
  --condition "category=Administrative and operationName=Microsoft.ContainerService/managedClusters/write" \
  --action-group "${AG_ID}" \
  --description "AKS cluster update/upgrade operation started — verify it is the expected auto-upgrade"

Key Takeaways

✓A maintenance window in AKS defines when an upgrade is permitted — not when it will run. Microsoft explicitly states these windows are best-effort. A skipped window is not a bug; it means one or more of the six required conditions was not satisfied.
✓The most common cause of a silently skipped auto-upgrade is a startDate set to a future date. Check this first: az aks maintenanceconfiguration show --name aksManagedAutoUpgradeSchedule --query maintenanceWindow.startDate. If the date is in the future, the window is not yet active.
✓The maintenance configuration must be named exactly aksManagedAutoUpgradeSchedule for cluster version auto-upgrades. A configuration named default only controls AKS weekly platform releases. Any other name is completely ignored.
✓When the auto-upgrade is silently skipped, there are no Activity Log entries — silence is itself the diagnostic signal. Absence of log entries means the upgrade was not attempted, which means one of the six gate conditions failed before any attempt was made.
✓Set minimum window duration to 4 hours for aksManagedAutoUpgradeSchedule. Shorter windows may not complete the upgrade cycle and can cause AKS to defer to the next window occurrence.
✓PDBs with maxUnavailable: 0 or minAvailable equal to total replicas block all drain operations and silently prevent upgrades. Audit PDBs across all namespaces before expecting auto-upgrades to run: kubectl get pdb --all-namespaces -o wide.
✓Set up Activity Log alerts on Create or Update Managed Cluster so you know when an upgrade actually starts. Without active monitoring, the only way to know if an upgrade ran is to compare the cluster version before and after the maintenance window.
Frequently Asked Questions
If the startDate was in the future and that was the cause, will the upgrade automatically run the next scheduled window after the startDate passes?
Yes. Once the startDate is in the past, the next occurrence of the configured schedule becomes an active maintenance window. If there is an eligible Kubernetes version on the Stable channel at that point and all other gates pass, the upgrade will execute. You do not need to manually trigger it — you just need to ensure the startDate is corrected to a past date. After fixing the startDate, verify by running az aks get-upgrades to confirm an eligible version exists, then wait for the next scheduled window occurrence.
My cluster is on 1.33.7 and the Stable channel shows no available upgrades. When will a new version appear?
The Stable auto-upgrade channel targets the latest patch of Kubernetes N-1 (the second-most-recent minor version). If 1.33.x is the current N-1 minor version and 1.33.7 is the latest patch in that minor, there is genuinely no available upgrade until either a newer patch of 1.33 is released, or the Stable channel shifts its target to a new minor version. Monitor the AKS release tracker at releases.aks.azure.com and specifically the West US 3 region status. New AKS releases take up to two weeks to reach all regions after initial publication.
Can I force a manual upgrade to the same target version that the auto-upgrade was supposed to apply?
Yes. If you want to trigger the upgrade immediately without waiting for the next maintenance window, you can run az aks upgrade --resource-group RG --name CLUSTER --kubernetes-version TARGET_VERSION. This runs immediately, outside any maintenance window. For a test environment this is typically acceptable. For production, consider whether running outside the maintenance window affects your change management compliance requirements. After a manual upgrade, the auto-upgrade configuration remains active and will apply future Stable channel versions during scheduled windows.
How do I get the Microsoft backend activity logs for the maintenance window if I cannot see them in the portal?
The Activity Log in the portal and CLI only contains customer-visible events. If an upgrade was silently skipped (not attempted), there is no backend log to retrieve — not from the portal, not from the CLI, and not via a support ticket. The backend only generates logs when an operation was attempted. For a silent skip due to gate conditions (startDate, wrong name, no eligible version), the absence of a log is the correct and expected behaviour. If you believe the upgrade was attempted and failed (not just skipped), open a support ticket with the cluster name, subscription, and the expected maintenance window timestamp — the support team has access to internal AKS service logs that are not visible in the portal.
Should I use the same aksManagedAutoUpgradeSchedule configuration across multiple AKS clusters in the same subscription?
No. Microsoft explicitly documents that using the same maintenance configuration across multiple clusters in a single subscription can lead to ARM throttling errors, causing cluster upgrades to fail. Each cluster should have its own maintenance configuration, and if possible, stagger the maintenance windows across clusters by a few hours to avoid simultaneous upgrade operations competing for ARM API quota. This is especially important in subscriptions with more than 5–10 clusters.

Related FAVRITE Articles

  • How to Fix Azure Database for PostgreSQL Flexible Server Stuck in Starting State
  • Least Privileged Access Required to View Azure App Service Log Stream
  • Top 50 Azure Cloud Administrator Interview Questions and Answers

Popular posts from this blog

The Cloud Incumbent: AWS Bedrock Hosts Every Frontier Model and Amazon Is Betting on Neutrality

The Cloud Incumbent: AWS Bedrock Hosts Every Frontier Model and Amazon Is Betting on Neutrality AWS at $37.6 billion quarterly revenue, growing 28%. $13 billion invested in Anthropic. A $100 billion Anthropic-to-AWS commitment. Trainium with $225 billion in customer revenue commitments. The most quietly powerful AI strategy in the race. By Francis Avorgbedor | Azure Engineer  ·  July 4, 2026  ·  14 min read  ·  Amazon · AWS · Cloud AI 74 SEVENAI Momentum Score — Rank #5 $37.6B AWS Q1 2026 revenue — 28% YoY growth ▲ Fastest in 15 quarters $13B Total Amazon investment in Anthropic to date ▲ Strategic anchor 100K+ Customers running Claude on AWS Bedrock ▲ Distribution moat Amazon's AI strategy is built on a thesis that every other Magnificent Seven company is testing against — and that Amazon is uniquely positioned to win regardless of the outcome. The thesis is neutrality. In a race where Microsoft has bet on OpenAI, Google has bet on Gemini, and Meta has bet...
Read more

The Importance of Content Marketing in 2026: Building Trust, Driving Leads and Growing Your Business

 The Importance of Content Marketing in 2026: Building Trust, Driving Leads and Growing Your Business Content marketing is not a passing trend – it has become the backbone of modern marketing and sales strategies. Companies that consistently educate and engage their audience with blogs, videos , podcasts and other formats are seeing measurable results in brand awareness, lead generation and revenue. By 2026, content marketing is no longer optional: over 82 % of companies use it and more than 54 % plan to increase their investment . In today’s competitive landscape, high‑quality, customer‑focused content builds trust, attracts qualified prospects and nurtures loyalty throughout the buyer journey. Pervasive adoption and why it matters Widespread usage: Research shows that 73 % of B2B marketers and 70 % of B2C marketers include content marketing in their strategies . Within organisations, dedicated content teams are becoming the norm; 73 % of major o...
Read more

How to Reset an Azure Virtual Machine to Factory Settings Using a Managed Disk

How to Reset an Azure Virtual Machine to Factory Settings Using a Managed Disk Azure does not have a single "factory reset" button. What it does have is something better: the OS Disk Swap — a method that swaps out the corrupted or misconfigured OS disk for a clean Windows Server managed disk without deleting the VM, its NICs, its IP addresses, or any attached data disks. Here is how it works, when to use it, and the exact steps to execute it safely. FA Francis Avorgbedor Azure Engineer July 16, 2026 15 min read Azure VMs · Windows Server · Real-World Fix 3 Methods to achieve a clean Windows Server installation on an existing Azure VM ~15min Typical OS Disk Swap duration — VM retains its NICs, IPs, and data disks throughout 0 Data disks affected by an OS Disk Swap — data disks remain attached and untouched 1 Snapshot of the original OS disk you must take before starting — no exceptions Introduction Why Azure Does Not Have a Simple Factory Reset — and What to Do Instead On a ph...
Read more
  A slow or unstable internet connection can be incredibly frustrating, but many common issues can be resolved with a bit of troubleshooting. This guide will walk you through a series of steps to diagnose and fix your internet connection. Step 1: Basic Checks & Restarting Your Equipment Often, the simplest solutions are the most effective. Check Cables:  Ensure all cables connected to your modem and router are securely plugged in. This includes the power cables, the Ethernet cable connecting your modem to your router (if you have separate devices), and the cable coming from your internet service provider (ISP) – usually coaxial or fiber optic. Restart Your Modem and Router:  This is the golden rule of internet troubleshooting. Unplug  both your modem and router from their power sources. Wait for at least  30 seconds . This allows the devices to fully power down and clear their temporary ...
Read more

Can I Update My Old Computer to Windows 11 — and How Much Will It Cost?

Can I Update My Old Computer to Windows 11 — and How Much Will It Cost? Your i7, 16GB RAM, 512GB SSD machine is powerful enough to run Windows 11 comfortably. The TPM 2.0 and Secure Boot wall is a security checkbox, not a performance ceiling. Here are two proven ways to get past it, what each one costs, and what you are trading away by doing so. $0 Cost of the Windows 11 licence if your existing Windows 10 is genuine — the upgrade remains free in 2026 2 Proven methods to bypass TPM 2.0 and Secure Boot — Rufus (easy) and Registry edit (manual) 25H2 Current Windows 11 version — all known bypass methods tested and confirmed working as of July 2026 Oct 2025 Windows 10 end of life — no more security updates. Staying on Windows 10 now carries real risk. First — Check Your BIOS Before Anything Else You Might Not Actually Need a Bypass Before running any bypass, open your BIOS and look at two settings. Many computers that fail the Windows 11 compatibility check have TPM 2.0 present in the hard...
Read more

Azure Files vs Azure NetApp Files: Which One Should You Choose?

Azure Files vs Azure NetApp Files: Which One Should You Choose? Performance tiers, protocol support, dual-protocol capability, pricing models, SAP/Oracle/HPC suitability, data management features, and the decision framework that maps each workload type to the right service — with step-by-step setup procedures for both. FA Francis Avorgbedor Azure Engineer July 15, 2026 20 min read Azure Storage · Architecture 4 Azure Files tiers: Premium SSD, Standard Hot, Cool, Tx Optimized 3 ANF performance tiers: Standard, Premium, Ultra — all SSD-backed 4TiB ANF minimum provisioning — significant cost floor for small workloads Dual ANF serves the same data via SMB and NFS simultaneously — AF cannot Introduction Two Services, One Surface Area — Completely Different Purposes Microsoft offers two fully managed, enterprise-grade file storage services in Azure. They share a surface area — both serve file shares over standard protocols, both run on managed infrastructure, and both integrate with Microsof...
Read more
 Digital Marketing Trends and Strategies for SMBs in 2026 Small and mid‑sized businesses (SMBs) are competing in an environment where digital marketing changes faster than ever. The rise of artificial intelligence (AI), voice search and social commerce are reshaping how customers discover, evaluate and purchase products. To succeed, SMBs must understand the trends shaping 2026 and implement strategies that build trust, visibility and conversion—without breaking the budget. AI becomes the backbone of digital marketing AI‑driven personalization is now standard. Advances in machine learning mean even small businesses can personalize messaging at scale. Twilio’s research shows that 92 % of companies use AI‑driven personalization to drive growth . AI tools automate tasks like content creation, segmentation and performance analysis, freeing owners to focus on strategy . AI marketing tools are accessible. According to a U.S. Chamber of Commerce report cited by Thryv, 58...
Read more
 Social Media Monetization for Beginners Social media platforms offer numerous avenues for monetization, even for beginners without specialized skills. The key lies in understanding different strategies, creating valuable and authentic content, and consistently engaging with an audience. Here are the primary ways one can monetize social media: • Direct Monetization Methods     ◦ Sponsored Posts and Brand Partnerships: Once you build a decent following, companies will pay you to promote their products or services through your posts, stories, or videos. These often involve a fixed fee per post or campaign and require you to demonstrate influence and an active community. It's crucial to promote products you genuinely like and to be transparent with disclosures about paid partnerships.     ◦ Affiliate Marketing: This involves promoting other companies' products or services using unique links. You earn a commission when someone makes a purchase through your link. Pla...
Read more
Creating user profiles for Entra-joined Azure Virtual Desktops (AVD) primarily involves configuring FSLogix Profile Containers . This ensures that user profiles are portable and persistent across sessions, even though the session hosts are Entra-joined. Here's a step-by-step guide: Step 1: Prepare Your Storage for FSLogix Profiles You'll need a file share that can be accessed by your AVD session hosts and where user profile disks will be stored. Azure Files is a common and recommended solution for this. Create an Azure Storage Account : Go to the Azure portal, search for "Storage accounts," and click "Create." Choose your subscription and resource group. Give it a unique name (e.g., avdprofilesstorage). Select a region. For performance, consider "Premium" with "File shares" as the account kind, or "Standard" with "ZRS" or "GRS"...
Read more
Building Online Presence : A Skill-Free Income Guide Building a strong online presence is fundamental for generating income without prior skills, and it involves several key strategies, from mindset to practical execution. Foundational Mindset Shifts for Success Developing the right mindset is the starting point for building an online presence, influencing your motivation and ability to overcome challenges. • Embrace Learning and Adaptability Your ability to succeed online without specific skills starts with believing that change is possible and that you can learn as you go. The digital world changes rapidly, so being open to trying new methods and adapting your approach is crucial to keep moving forward. • Persistence Over Perfection View setbacks as opportunities to learn rather than failures, which helps build resilience. Recognize that success comes from persistence, not perfection. Small, consistent wins build confidence. • Focus on What You Control Concentrate on your effort, att...
Read more