Azure App Service retired Node 22 LTS for 30 April 2027 and named a target that expires 366 days later

Summary. Azure App Service published a Node 22 LTS retirement notice at 17:30 UTC on 24 August 2026, with support ending on 30 April 2027, 249 days out. The notice tells you to "upgrade your app to Node 24 LTS before April 30, 2027". The Node.js Release Working Group schedule puts Node 24 into maintenance on 20 October 2026, 57 days after the notice, and ends it on 30 April 2028, exactly 366 days after the Node 22 cliff. Node 26 becomes Active LTS on 28 October 2026 and runs to 30 April 2029, 731 days past the cliff. Following the notice literally buys 12 months of runway. Following the Node.js schedule buys 24. App Service plans in Central India ran from $0.018 per hour for Basic B1 Linux to $0.818 for Premium v4 P3v4 on 24 August 2026, so the runway is cheap and the migration is not.

What the notice says

The retirement record is terse and worth reading in full, because the operative sentence is the last one. "On April 30 2027, support for Node 22 LTS will end. Your apps that are hosted on App Service will continue to run, but security updates will no longer be available, and we'll no longer provide customer service for Node 22 LTS. Required action: To avoid potential security vulnerabilities and minimize risk for your App Service apps, follow the steps to upgrade your app to Node 24 LTS before April 30, 2027."

The Azure release record is filed against the App Service product with an availability ring of "Retirement" for April 2027. Nothing about the date is negotiable, because App Service does not set it. The language runtime support policy is explicit: "App Service follows community support timelines for the lifecycle of the runtime."

The date the notice does not mention

That policy sentence is what makes the recommended target odd. If App Service follows community timelines, the community timeline is the document that should decide your target version. Here is what it says, taken from schedule.json in the nodejs/Release repository.

Node.js version	Enters maintenance	End of life
20 (Iron)	22 October 2024	30 April 2026
22 (Jod)	21 October 2025	30 April 2027
24 (Krypton)	20 October 2026	30 April 2028
26	20 October 2027	30 April 2029
27	20 October 2027	30 April 2030

Node 22 has been in maintenance since 21 October 2025. That is 307 days before Microsoft sent the notice. Maintenance releases carry critical and security fixes only, so the narrowing everyone is being warned about started nearly ten months ago and the App Service date is the point where the platform stops relaying even those.

Node 24 has been Active LTS since 28 October 2025 and enters maintenance on 20 October 2026. That is 57 days after this notice was published. So the version Azure names as the fix will already be a maintenance release before most teams finish planning the change, and it ends 366 days after the version it replaces.

Question	Node 24 LTS (the notice's target)	Node 26 LTS
Active LTS from	28 October 2025	28 October 2026
Enters maintenance	20 October 2026	20 October 2027
End of life	30 April 2028	30 April 2029
Runway past the 30 April 2027 cliff	366 days	731 days
Still Active LTS on 30 April 2027?	No, in maintenance since 20 October 2026	Yes, until 20 October 2027

Five rows, and the fifth is the one that matters. If your reason for moving is "we want to be on a version that still gets full releases", Node 24 does not deliver that on the day the cliff arrives. Node 26 does.

Why the notice still says 24

There is a defensible reason, and it is worth stating plainly rather than treating the notice as a mistake. Node 26 does not become Active LTS until 28 October 2026, 65 days after the notice was written. Microsoft cannot name a version that is not yet an LTS line as the supported migration target, and the current App Service documentation reflects the same lag: the Node.js configuration guide uses WEBSITE_NODE_DEFAULT_VERSION="~24" on Windows and NODE|24-lts on Linux in its worked examples.

The practical consequence is a scheduling one. A team that starts the migration now and ships in Q4 2026 can land on Node 26 for the same effort, because the code changes between 22 and 24 and between 22 and 26 largely overlap. A team that follows the notice to the letter does the work twice.

What actually breaks

Three things, none of them the runtime.

You cannot pin a patch level to buy time. The language runtime support policy says App Service "updates major versions of stacks but can't guarantee any specific minor versions or patch versions" and that "the platform controls minor and patch versions". If you need a specific patch, the documented answer is a custom container, which moves runtime patching from Microsoft onto your build pipeline. That is a real operational transfer, not a config flag.

The rollback path closes. The Microsoft-maintained App Service Linux runtime notes state that "once a version of Node.js has reached it's end of life (EOL) it will no longer be available from Runtime Stack selection dropdown", while also saying that "existing applications configured to target a runtime version that has reached EOL should not be affected". Those two sentences sit badly next to a retirement notice that says security updates stop. The reconciliation: your app keeps running on the setting it already has, but you cannot select that setting again, so a post-cliff rollback from Node 24 to Node 22 is not a portal operation.

The notification may not reach the people who own the app. The support policy lists the roles that receive reminders as account administrators, service administrators and coadministrators, and states that "contributors, readers, or other roles don't directly receive notifications unless they opt in to receive notification emails by using Service Health Alerts". On a subscription where the platform team holds Contributor, nobody on that team is on the list by default.

What to do, in order

Inventory. On Linux, az webapp config show --resource-group <rg> --name <app> --query linuxFxVersion. On Windows, query the WEBSITE_NODE_DEFAULT_VERSION app setting. Both commands are in the App Service Node.js configuration guide.
Decide the target version against the Node.js schedule, not the notice. If you will ship after 28 October 2026, target Node 26 and skip a migration.
Subscribe the platform team to Service Health Alerts so the next retirement notice reaches the people who own the change.
Change the stack setting last. The runtime support notes warn that changing stack settings restarts the application, so it belongs in a maintenance window with a slot swap behind it.

Do not treat this as a version bump. The real cost is usually the dependency tree, not the runtime: native modules compiled against a V8 ABI, packages that pinned an engines range at Node 22, and build images in your pipeline that still install 22.

What the plan costs while you migrate

These are Azure Retail Prices API values for Linux App Service plans in Central India, queried on 24 August 2026.

Tier	SKU	USD per hour
Basic	B1	0.018
Basic	B2	0.036
Standard	S3	0.352
Premium v4	P1v4	0.204
Premium v4	P3v4	0.818

Five rows. The runtime itself carries no line item in that result set, which is the point: the retirement costs you engineering time, not Azure spend.

India-specific considerations

For teams running App Service from Central India, the 30 April 2027 date lands in the first month of the Indian financial year, which is usually the worst possible window for an unplanned platform change. Pulling the work into the 2026-27 financial year is the cheaper choice on both the budget and the risk side. Where the application processes personal data, note that running a runtime with no security updates past 30 April 2027 is difficult to defend as a reasonable security safeguard under the Digital Personal Data Protection Act 2023, and the App Service notice is now dated evidence that you were told.

What is still unknown

Microsoft has not published an App Service availability date for Node 26, and the Node.js configuration guide still shows Node 24 in its examples. Whether App Service adds a Node 26 stack option shortly after 28 October 2026, and whether the retirement notice is later amended to name it, are both open as of 24 August 2026.

FAQ

What did Azure announce on 24 August 2026?

App Service published a retirement notice for Node 22 LTS with an end date of 30 April 2027. Apps keep running after that date, but Microsoft stops shipping security updates and stops providing customer support for the runtime. The notice names Node 24 LTS as the upgrade target.

Why is Node 24 a weak migration target?

The Node.js release schedule puts Node 24 into maintenance on 20 October 2026 and ends it on 30 April 2028. That is 366 days past the Node 22 cliff. Node 26 becomes Active LTS on 28 October 2026 and runs to 30 April 2029, which is 731 days.

Has Node 22 already lost anything?

Yes. The Node.js release schedule shows Node 22 entered maintenance on 21 October 2025, which is 307 days before Azure sent this notice. Maintenance releases carry critical and security fixes only. The App Service retirement date is the point where Microsoft stops relaying those fixes to the platform stack.

Can I pin a specific Node 22 patch version to buy time?

No. The Azure language runtime support policy says App Service updates major versions but cannot guarantee any specific minor or patch version, and that the platform controls those. The documented escape hatch is a custom container, which moves runtime patching from Microsoft onto your own build pipeline.

Will Node 22 disappear from the portal?

The Microsoft-maintained App Service Linux runtime support notes state that once a Node.js version reaches end of life it is no longer available from the Runtime Stack selection dropdown. Existing apps keep their setting, but you lose the ability to select it again, so a rollback after the date is not a portal operation.

Who receives the retirement notification?

Azure's language runtime support policy says reminder notifications go to subscription owners, and lists account administrators, service administrators and coadministrators as the roles that receive them. Contributors and readers do not, unless they opt in through Service Health Alerts. That routing is why platform teams often learn about a retirement late.

How do I change the Node version on App Service?

On Linux, set the runtime through the linux-fx-version property, for example NODE|24-lts using az webapp config set. On Windows, set the WEBSITE_NODE_DEFAULT_VERSION app setting with tilde syntax such as ~24. Both changes restart the application, so schedule them in a maintenance window.

What does the migration runway cost?

The Azure Retail Prices API returned 0.018 US dollars per hour for a Basic B1 Linux App Service plan in Central India on 24 August 2026, 0.036 for B2, 0.352 for Standard S3 and 0.204 for Premium v4 P1v4. Those figures are list prices for the plan in that region on that date.

How eCorpIT can help

Runtime retirements are the cheapest migrations to plan and the most expensive to postpone. Our cloud migration and modernization practice handles App Service runtime moves as dependency work first and stack-setting work last, which is the order that keeps the rollback usable. If your estate has Node 22 apps and no inventory of them, ask for an App Service runtime audit and we will start with linuxFxVersion across the subscription. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 appraised.