Azure Kubernetes Service end of support notifications

Azure Kubernetes Service (AKS) proactively notifies you when your cluster's Kubernetes version is approaching or has passed its end of support date. These notifications are published as scheduled events to Azure Resource Graph (ARG) through the AKS Communication Manager, using the same Azure Resource Notifications pipeline as maintenance notifications.

End of support notifications are automatic and don't require auto-upgrade or a maintenance window to be configured. No cluster monitoring add-on is required.

Notification types

AKS evaluates your cluster's Kubernetes version against the AKS Kubernetes release calendar and sends notifications at the following intervals:

Notification	When it fires	Description
`KubernetesVersionEOLTwoWeeks`	14 or more days before end of support	Your cluster version reaches end of support within two weeks
`KubernetesVersionEOLOneWeek`	7 to 14 days before end of support	Your cluster version reaches end of support within one week
`KubernetesVersionOutOfSupport`	After end of support date	Your cluster version is past end of support (repeats weekly)

Note

Clusters using Long Term Support (LTS) are evaluated against the LTS end of support date, which is later than the community end of support date. For current lifecycle dates, see the AKS Kubernetes release calendar.

Notification payload

Each notification includes structured event details that you can use for automation or reporting:

{
  "description": "KubernetesVersionEOLOneWeek",
  "eventSource": "EOLNotification",
  "eventStatus": "Scheduled",
  "eventDetails": {
    "kubernetesVersion": "1.32.3",
    "eolDate": "2026-03-01T00:00:00Z",
    "supportType": "Community",
    "daysUntilEOL": 5,
    "region": "eastus"
  },
  "scheduledTime": "2026-03-01T00:00:00Z"
}

The eventDetails field contains:

kubernetesVersion: The full version running on your cluster
eolDate: The end of support date for this version
supportType: Community or LTS, depending on your cluster's support plan
daysUntilEOL: Days remaining until end of support (negative if already past)
region: The Azure region of the cluster

Query notifications in Azure Resource Graph

You can check whether your cluster has end of support notifications by querying Azure Resource Graph directly. No cluster monitoring is required for these queries.

Note

For each query, update the where id contains path to reference your subscription ID, resource group name, and cluster name.

Query for a specific cluster

containerserviceeventresources
| where type == "microsoft.containerservice/managedclusters/scheduledevents"
| where id contains "/subscriptions/<subid>/resourcegroups/<rgname>/providers/Microsoft.ContainerService/managedClusters/<clustername>"
| where properties has "EOLNotification"
| extend description = tostring(properties.description)
| extend details = parse_json(tostring(properties.eventDetails))
| project name, description, details, properties

Query for all notifications across subscriptions

containerserviceeventresources
| where type == "microsoft.containerservice/managedclusters/scheduledevents"
| where properties has "EOLNotification"
| extend description = tostring(properties.description)
| extend details = parse_json(tostring(properties.eventDetails))
| project name, description, details, properties
| order by name asc

Query from the Azure portal

You can run these queries directly in the Azure portal:

Go to the Azure portal and search for Resource Graph Explorer.
Paste one of the queries above into the query editor.
Select Run query to see results.

You can also access Azure Resource Graph from Azure Monitor without needing the monitoring add-on enabled on your cluster.

Set up email alerts

To receive email notifications when your cluster approaches its end of support date, create a log search alert rule. This follows the same pattern as maintenance notifications.

Go to the resource, then choose Monitoring and select Alerts and then select Alert Rules.
The Condition for the alert should be a Custom log search.
In the opened "Search query" box, paste the following query. Update the path placeholders with your subscription ID, resource group name, and cluster name.

arg("").containerserviceeventresources
| where type == "microsoft.containerservice/managedclusters/scheduledevents"
| where id contains "/subscriptions/<subid>/resourcegroups/<rgname>/providers/Microsoft.ContainerService/managedClusters/<clustername>"
| where properties has "EOLNotification"
| extend description = tostring(properties.description)
| extend details = parse_json(tostring(properties.eventDetails))
| extend eventTime = todatetime(tostring(properties.lastUpdateTime))
| where eventTime >= ago(2h)
| project eventTime, description, details, name, properties
| order by eventTime asc

Configure the alert conditions with the following settings:
- Measurement: Select "Table rows"
- Aggregation: Select "Count"
- Aggregation granularity: Select "30 minutes"
- Threshold value: Keep at 0
- Split by dimensions: Select "description" and choose "Include all future values"
Note

Splitting by the "description" dimension creates separate alerts for each notification type: KubernetesVersionEOLTwoWeeks, KubernetesVersionEOLOneWeek, and KubernetesVersionOutOfSupport. These values only appear after your cluster has received its first notification.
Check that an action group with the correct email address exists to receive the notifications.
Assign Managed System Identity: After you create the alert rule, assign a managed identity so it can access the necessary resources. To assign a managed identity:
- In the Azure portal, go to Monitor > Alerts > Alert rules, then select your alert rule.
- In the alert rule pane, under Settings, select Identity.
- Set System assigned managed identity to On.
- Select Save to enable the managed identity for the alert rule.
Tip

If you don't see the Identity option, make sure your alert rule has been created and you have the necessary permissions. Assigning the managed identity is always a separate step after alert rule creation.
Make sure to assign the appropriate Reader roles.

In the alert rule, go to Settings > Identity > System assigned managed identity > Azure role assignments > Add role assignment.

Choose the Reader role and assign it to the resource group. Repeat "Add role assignment" for the subscription if needed.

Verification

Check the Azure Resource Graph for notification records using the query above. Each notification is listed as one record in the containerserviceeventresources table.

Screenshot that shows how to look up Azure Resource Graph.

In addition to querying Azure Resource Graph and setting up log search alerts, you can receive real-time notifications through Azure Event Grid webhooks. This approach pushes notifications to your endpoint (such as a Logic App, Azure Function, or custom webhook) as soon as they're published.

All AKS scheduled events, including end of support notifications and maintenance notifications, are published through the same Event Grid system topic.

Create a system topic

Create an Azure Resource Notifications (ARN) system topic for your subscription. This only needs to be done once per subscription.

az eventgrid system-topic create \
  --name aks-scheduled-events \
  --resource-group <resource-group> \
  --source /subscriptions/<subscription-id> \
  --topic-type microsoft.resourcenotifications.containerserviceeventresources \
  --location global

Create an event subscription

Create an event subscription that routes notifications to your endpoint:

az eventgrid event-subscription create \
  --name aks-eol-notifications \
  --source-resource-id /subscriptions/<subscription-id> \
  --endpoint <your-webhook-url> \
  --included-event-types Microsoft.ResourceNotifications.ContainerServiceEventResources.ScheduledEventEmitted

To filter notifications to a specific resource group, add subject filtering:

  --subject-begins-with /subscriptions/<subscription-id>/resourcegroups/<resource-group-name>

Note

The Event Grid system topic delivers all scheduledEvents for the subscription, including both maintenance and end of support notifications. Filter by eventSource in your endpoint logic: EOLNotification for end of support events, AutoUpgrader for maintenance events.

AKS scheduled event notification types

AKS publishes notifications through the containerserviceeventresources table in Azure Resource Graph. The following table lists all notification types:

Category	Event source	Notifications	Description
End of support	`EOLNotification`	`KubernetesVersionEOLTwoWeeks`, `KubernetesVersionEOLOneWeek`, `KubernetesVersionOutOfSupport`	Proactive alerts when a cluster's Kubernetes version is approaching or has passed end of support
Maintenance	`AutoUpgrader`	`Scheduled`, `Started`, `Completed`, `Failed`, `Cancelled`	Notifications about upcoming and in-progress auto-upgrade maintenance windows

Both categories use the same scheduledEvents resource type and can be queried, alerted on, and subscribed to using the same approaches described on this page and the AKS Communication Manager page.

How notifications work

End of support notifications are evaluated periodically by the system for every cluster. No configuration is required on the cluster itself.

Community vs LTS: The system checks your cluster's support plan. Community clusters are evaluated against the community end of support date. LTS clusters use the later LTS end of support date.
Notification frequency: Each notification type (KubernetesVersionEOLTwoWeeks, KubernetesVersionEOLOneWeek) is sent once per cluster version. After the end of support date has passed, KubernetesVersionOutOfSupport notifications are sent weekly as a reminder.
Version upgrade resets notifications: If you upgrade your cluster to a newer Kubernetes version, the notification status resets and new notifications are evaluated against the new version's end of support date.
No monitoring required: These notifications are written to Azure Resource Graph and don't require the monitoring add-on to be enabled on your cluster. You can query them from any Azure Resource Graph client, including the Azure portal Resource Graph Explorer, Azure Monitor, Azure CLI, or the REST API.

AKS Kubernetes release calendar for current version lifecycle dates.
Set up the AKS Communication Manager for maintenance notification alerts.
Long Term Support for AKS for extended support on Kubernetes versions.
Subscribe to AKS events with Event Grid for real-time webhook notifications.
Upgrade options for AKS clusters when your version approaches end of support.

Feedback

Was this page helpful?

Last updated on 2026-06-12

Azure Kubernetes Service end of support notifications

Notification types

Notification payload

Query notifications in Azure Resource Graph

Query for a specific cluster

Query for all notifications across subscriptions

Query from the Azure portal

Set up email alerts

Verification

Subscribe to real-time notifications with Event Grid

Create a system topic

Create an event subscription

AKS scheduled event notification types

How notifications work

Related content

Feedback

Additional resources