Microsoft posted a retirement notice on the Azure Updates roadmap on September 22: support for Azure Functions apps running Node.js 22 ends on April 30, 2027. After that date your function apps keep running, but they stop getting security patches, updates, and customer support for the runtime.
That is the standard Azure runtime retirement pattern, and the seven months of lead time is the point. Microsoft publishes these notices specifically so teams can plan, test, and migrate before the clock runs out. Seven months is enough if you start this quarter. It is not enough if you discover the problem in March.
What actually happens after April 30
Your apps do not shut off. Azure Functions apps on Node.js 22 continue to run, but the runtime becomes unsupported: no security fixes, no updates, and support tickets about Node.js 22 behavior get declined. Azure’s language support policy also describes a phased reduction, starting with a notification phase where subscription owners get emails, followed by a retirement phase that can limit scaling to a single instance.
The scaling limit is the detail most people miss. An unsupported runtime that can only scale to one instance is not just a security problem, it is a reliability problem the next time your queue backs up.
The date should not surprise anyone
Node.js 22 (codename Jod) entered Maintenance LTS on October 21, 2025, and its community end of life is April 30, 2027, per the official Node.js release schedule. Azure’s retirement date matches the upstream EOL exactly. That is deliberate. Azure Functions ties its runtime support windows to community EOL dates, so a Node version’s Azure lifespan is knowable the day it ships.
The upgrade target is Node.js 24 (codename Krypton), which is Active LTS until April 30, 2028. It shipped in May 2025 with V8 13.6, npm 11, Undici 7, a global URLPattern, and a stabilized permission model. Going to 24 rather than an odd-numbered release keeps you on a line with real long-term support.
The Linux Consumption catch
Here is the part that turns a version bump into a migration. Node.js 22 is the last Node version supported on the Azure Functions Linux Consumption plan, according to the supported languages doc. Newer Node versions are only added to Flex Consumption. If your app runs on Linux Consumption, you cannot just pick Node.js 24 in the portal. You have to move plans and upgrade the runtime at the same time.
Flex Consumption changes billing and scaling behavior, so budget time to test under the new plan rather than treating this as a dropdown change. If you are on Premium or Dedicated plans, the upgrade is genuinely closer to a config edit.
How to find and fix affected apps
The practical order of operations:
- Inventory first. Microsoft published Azure CLI scripts for identifying function apps on retiring language versions. Run them across every subscription, including the ones nobody remembers creating.
- Then audit for breaking changes between Node 22 and Node 24. The usual suspects: removed APIs like
tls.createSecurePair()and deprecated uses ofurl.parse(). If your dependencies are pinned to old majors, check their changelogs now, not during the migration. - Upgrade in a staging slot or a dev function app first, then deploy. The Node version is set through the app’s language version configuration, and Microsoft’s update guide covers the exact settings.
- If anything sits on Linux Consumption, plan the Flex Consumption move separately. Do the plan migration and the runtime upgrade as two reviewed changes, not one big bang.
Also watch for the notification emails. Azure sends retirement warnings to subscription owners during the notification phase, and portal banners appear on affected apps. If nobody on your team owns those notifications, they read like noise until they don’t.
What ignoring it costs
It helps to be concrete about the exposure. An unpatched runtime does not mean the vulnerabilities stop arriving. New CVEs in V8, in the Node core HTTP stack, or in OpenSSL get fixed upstream, and Node 22 stops receiving those fixes after April 2027. Any function app reachable from the internet, webhook handlers and API endpoints especially, accumulates known-but-unfixed vulnerabilities from that point on. Combine that with the scaling cap from the retirement phase and the failure mode is ugly: an app that is both less secure and less able to absorb traffic spikes. No compliance auditor will accept the argument that the app still runs as a mitigation either.
None of this is expensive to fix while the runbook exists. It gets expensive when done under pressure after the deadline, on an unsupported runtime, with Microsoft support politely declining to help.
Why this pattern matters beyond Node
Azure Functions retirement dates have tracked community EOL dates for a while now, and other managed runtimes do the same. The useful takeaway is that the deadline was computable a year ago. If you maintain a serverless estate, the habit worth building is checking the supported languages page after every LTS release, because your upgrade window is defined the day the runtime ships. The teams that get burned by these retirements are almost always the ones that treated runtime versions as infrastructure that would quietly stay supported forever.
Seven months is a comfortable runway. Use it.