Insights

The App Service retirement notice goes to someone who is not you

Braintree Insights | 25 August 2026

The App Service retirement notice goes to someone who is not you

Microsoft announced on 24 August 2026 that Node 22 LTS support on App Service ends on 30 April 2027. The date is eight months away and is not the point. The policy behind it says apps on an unsupported runtime keep running unchanged, that Microsoft cannot provide security patches or support for that runtime, that an app must be upgraded before it can get App Service support at all, and that the reminder notices go to subscription administrators rather than to the people who maintain the apps.

A single luminous jade thread travelling out of a soft glow and drifting past a cluster of dark, unlit forms without touching any of them.

What changed

Microsoft published the retirement notice on 24 August 2026: support for Node 22 LTS on App Service ends on 30 April 2027, apps hosted on App Service will continue to run, security updates will no longer be available, customer service for Node 22 LTS will no longer be provided, and the required action is to upgrade the app to Node 24 LTS before that date. Node 24 is confirmed available on the platform today, set on Linux with the runtime value NODE|24-lts and on Windows through the WEBSITE_NODE_DEFAULT_VERSION application setting using the tilde form. Behind that specific notice sits a policy that applies to every language on App Service, not only Node, and it is the policy that makes this worth acting on now. Microsoft states that after community support for a language reaches end of support, applications using that language continue to run unchanged, but App Service cannot provide security patches or related customer support for that runtime version past its end-of-support date. It adds, in its own emphasised callout, that if an app uses an unsupported language version it must be upgraded to a supported language version before it can get App Service support. And on notifications it states that App Service sends reminder notifications to subscription owners, that the roles receiving them are account administrators, service administrators and coadministrators, and that contributors, readers and other roles do not directly receive notifications unless they opt in through Service Health alerts.

The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.

What the term means in plain language

Azure App Service runs web applications on a managed platform, with the language runtime supplied and patched by Microsoft rather than by the application team. A language runtime version, such as Node 22 or Node 24, is the version of that engine the app runs on. App Service follows the community support timeline for each language, so the end-of-support date is set by the language’s own maintainers rather than by Microsoft. Service Health is the Azure service that publishes platform notifications, including retirement notices, and it can raise alerts to any recipient or action group a customer configures.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

Microsoft announced on 24 August 2026 that Node 22 LTS support on App Service ends on 30 April 2027. The date is eight months away and is not the point. The policy behind it says apps on an unsupported runtime keep running unchanged, that Microsoft cannot provide security patches or support for that runtime, that an app must be upgraded before it can get App Service support at all, and that the reminder notices go to subscription administrators rather than to the people who maintain the apps.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

Nothing about this fails loudly, which is exactly why it needs a decision rather than a diary entry. An app on a retired runtime keeps serving traffic, returns no error and raises no alert. Microsoft even documents that outdated runtimes are removed from the create and configure pages in the portal while any app still using one continues to run, so the runtime disappearing from the interface is not a signal that anything stopped. The consequence surfaces at the worst possible moment: Microsoft’s position is that an app on an unsupported version must be upgraded before it can get App Service support, so the day a production incident requires Microsoft’s help is the day the team discovers it is not eligible for it. The second half of the decision is about routing, and it is the cheaper of the two to fix. The people who receive Microsoft’s reminders are subscription administrators; the people who would act on them are contributors who maintain the applications. Microsoft states the gap plainly and also states the remedy, which is that other roles can opt in to receive notification emails using Service Health alerts. Braintree’s view, not Microsoft’s, is that this routing gap is where most runtime deadlines are actually missed, and it is not a discipline problem: a notice delivered to someone with no context on which apps run which runtime is not a notice at all. The useful outcome of this particular announcement is therefore not a Node upgrade eight months out. It is a runtime inventory that did not exist before, and an alert rule that makes every subsequent retirement arrive in front of the person who can act on it. Both are a morning’s work and neither expires.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

The inventory is a single query per app and can be scripted across subscriptions. On Linux, the runtime is read from the app’s linuxFxVersion property; on Windows, Node specifically is read from the WEBSITE_NODE_DEFAULT_VERSION application setting. The set of versions the platform currently offers can be listed per operating system, which gives the reference list to compare the inventory against. Record language, version, operating system, subscription and resource group for every app, and flag any app whose version is not in the currently supported list, because those are already in the unsupported state rather than approaching it. For the Node 22 upgrade specifically, the target is set on Linux by configuring the runtime to NODE|24-lts and on Windows by setting WEBSITE_NODE_DEFAULT_VERSION to the tilde form for version 24. Microsoft’s guidance is to target the major version rather than a specific minor or patch version, because the platform patches and updates minor versions itself and specific patch versions are not guaranteed to remain available; it also recommends setting the Node version in the project’s package.json, since the deployment engine runs in a separate process containing all supported versions. Where a specific minor or patch version genuinely is required, Microsoft’s answer is a custom container rather than pinning the platform runtime. For the notification fix, create a Service Health alert on service issues and health advisories, attach an action group containing the distribution list or team channel that maintains the applications, and verify it by confirming a test notification arrives rather than assuming the rule fired. Do it once at subscription level and it covers every future runtime retirement, not only this one.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: The application owner, with whoever holds subscription administrator rights on the Azure subscriptions running App Service.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Inventory the language runtime version of every App Service app across every subscription, which is a single CLI query per app. Then create a Service Health alert that routes Azure service and retirement notifications to the team that maintains the apps, rather than relying on the subscription administrator to forward them.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The dated runtime inventory listing every app with its language, version and subscription, the Service Health alert rule with its action group and the list of recipients it notifies, and a dated upgrade plan for any app on a runtime that is already out of support.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

What is the actual deadline?

30 April 2027 for Node 22 LTS on App Service. Microsoft’s stated required action is to upgrade the app to Node 24 LTS before that date.

Will our app stop working on that date?

No. Microsoft states apps continue to run unchanged. What stops is security patching for the runtime and Microsoft’s ability to support that runtime version.

So why act now if it still runs?

Because Microsoft states that an app on an unsupported language version must be upgraded to a supported version before it can get App Service support. The absence of a visible failure is the risk, not the reassurance.

Does this apply only to Node?

No. The retirement notice is about Node 22, but the support policy applies to every language runtime on App Service, including .NET, Java, Python, PHP and Go, each following its own community support timeline.

Who gets told about these retirements?

Microsoft states that reminder notifications go to subscription owners, specifically account administrators, service administrators and coadministrators.

Why did our developers not receive one?

Microsoft states that contributors, readers and other roles do not directly receive notifications unless they opt in to receive notification emails using Service Health alerts.

How do we fix the routing?

Create a Service Health alert with an action group that notifies the team maintaining the applications. Configured once at subscription level, it covers every future runtime retirement.

Is Node 24 available on App Service now?

Yes. Microsoft documents setting it on Linux as NODE|24-lts and on Windows through the WEBSITE_NODE_DEFAULT_VERSION setting using the tilde form for version 24.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.

Related Posts

eBPF host routing in Advanced Container Networking Services...
PostgreSQL 11, 12 and 13 left Azure standard...
The Azure VPN Client for Linux never left...