Kubernetes Patch Releases Are Running Late

Kubernetes patch rounds ran 8 to 9 days late from July to September 2026, and AKS lagged upstream by a median 44 days. The data and what to change.

Update, October 24, 2026: The October round was postponed to October 20 to pick up new Go releases and CVE fixes. As of the morning of October 24 it still had not been tagged, 11 days past the original target, and schedule.yaml still listed October 13.

The Kubernetes release calendar said the October patches would ship on October 13, 2026. Four days later, the GitHub release list still shows 1.37.1, 1.36.5, 1.35.9, and 1.34.12 as the newest patches. Those came out on September 23, eight days after their own target.

That matters more than it sounds. Patch dates feed vulnerability SLAs, change windows, and the “we’ll be on the fix by next Tuesday” promises in incident channels. If the planning date and the real date drift apart by a week or more, every one of those plans is wrong by the same amount. We compared the published schedule with the actual release dates for every patch round since September 2025, then measured how long one managed provider took to pick each patch up.

What the schedule promises

The patch release policy is short: “Our typical patch release cadence is monthly.” The early patches after a new minor release can come faster, and critical fixes can trigger an out-of-band release. Each round has a cherry-pick deadline, “typically two days before the target release.” The project also says it aims “to not make releases during major holiday periods.”

Every planned date lives in a machine-readable file, data/releases/schedule.yaml in the website repository. Each patch has a targetDate and a cherryPickDeadline, and a note when a month was skipped or a release happened off-cycle. That file is the plan. The actual release is the tag and the GitHub release that k8s-release-robot publishes, so we compared the two.

Target date versus release date

For each patch round from September 2025 to September 2026, we took the targetDate from the schedule and the publication date of the matching GitHub release. Where several branches shipped in the same round, they shipped within a day of each other.

The first eight rounds in the table were on time or a day late. Starting in June, every round has slipped, and the last three by more than a week. Annotated tags tell the same story: v1.34.10 was tagged on July 22 and v1.34.12 on September 23. Two months were skipped on purpose. The schedule notes say October 2025 and January 2026 patches were “consolidated” into the next round. The February 26 release was an out-of-band build to pick up a new Go version with security fixes.

The public record doesn’t say why the summer rounds slipped. Last Week in Kubernetes Development reported 1.36.3 as built with Go 1.26.5 and listed its fixes, but gave no reason for the timing. Treat the slip as a measured pattern, not a known cause. It could reverse next month.

The website shows the plan, not the release

One detail catches people out. The Kubernetes 1.36 release page lists “Latest patch release 1.36.5 (Released on 2026-09-15).” September 15 was the target date. The GitHub release for 1.36.5 was published on September 23. The page’s patch table has a “Target Date” column, and the summary line reuses it as the release date.

If a compliance report, a dashboard, or a script reads release dates from kubernetes.io, it can be off by a week. Read the date from the tag or the GitHub release instead:

# Newest stable patch tags with publication dates
curl -s "https://api.github.com/repos/kubernetes/kubernetes/releases?per_page=20" \
  | jq -r '.[] | select(.prerelease == false) | "\(.tag_name)\t\(.published_at)"'

The longer rhythm: minors and support

Patch timing sits inside a steadier minor-release cycle. Across 1.26 to 1.37, a new minor release arrived every 112 to 133 days, with a median of 126, which is roughly three a year. The first patch after a minor release arrived after a median of 27.5 days, from 2 days for 1.27.1 to 54 days for 1.35.1.

Support windows are just as regular. The four active branches in the schedule run 426 to 438 days from release to end of life. Each branch that reached end of life between 1.26 and 1.33 got 13 to 16 patch releases. The current oldest branch is the one to watch: Kubernetes 1.34 has been in maintenance mode since August 27, and the 1.34 release page gives an end-of-life date of October 27, 2026. The delayed October round includes 1.34.13, so it is probably the last 1.34 patch. If it ships late, clusters on 1.34 get very little time with the final patch before end of life.

How long a managed provider takes

Most teams don’t install upstream binaries. They wait for their provider. To put a number on that second delay, we read every 2026 release note in the Azure/AKS repository that says new Kubernetes patch versions “are now available.” We measured from the upstream GitHub release to the AKS release, using the release tag date, which marks the start of the AKS rollout.

Across 28 patch versions, the lag ran from 17 to 88 days, with a median of 44. It has come down since the winter, when it was close to three months. As of October 17, no AKS release note yet listed the August patches (1.36.4, 1.35.8, 1.34.11) or the September patches. The September round fixed CVE-2026-76654 in the Windows kubelet and CVE-2026-2270 in the StatefulSet controller.

These numbers cover release notes for one provider. AKS can also roll out fixes in other ways, and other providers run their own schedules, so check yours before you use these figures. The raw data for both tables is published as JSON.

What to change in your process

Two delays add up: upstream can ship a week or more after the calendar date, and your provider can take one to three months after that. A few adjustments make plans match reality.

1. Start SLA clocks at the tag, not the calendar. For a fix in a scheduled round, set the expected upstream date to the target plus about ten days until the slip ends. For a provider-managed cluster, add your provider’s measured lag on top.
2. Watch the schedule file, not the web page. A GitHub watch or a daily diff of schedule.yaml tells you when targets move, and the kubernetes-announce list tells you when releases actually ship.
3. Ask the provider directly. On AKS, az aks get-versions --location <region> --output table lists the patch versions you can actually select in a region, which is the number that matters for an upgrade window.
4. Track where your clusters actually are. kubectl version shows the API server, and kubectl get nodes -o wide shows each kubelet. The version skew policy allows kubelets to trail the API server, so a patched control plane doesn’t mean patched Windows nodes.
5. Get off 1.34 now. With end of life on October 27 and its last patch late, waiting for 1.34.13 before planning the move to 1.35 or later leaves almost no margin. The 1.37 upgrade readiness checklist covers the API removals to check first.

When you edit node-pool or control-plane manifests for the upgrade, run them through the Kubernetes YAML linter before you apply them.

Recommended reading

• Kubernetes 1.37 upgrade readiness checklist
• kubectl cheat sheet for 2026
• Debugging Kubernetes readiness probes

Tags: #kubernetes, #patch-releases, #release-cadence, #aks, #upgrades, #original-data