Updating Azure Functionapp to Node 22 runtime ahead of Node 20 deprecation at the end of April

Hey Blake Yarbrough

it sounds like you’ve aligned your Function App to Node 22 but the staging slot is hitting a 503 because the host spins up then immediately exits (exit code 0) with a gRPC timeout in an external startup class.

Since you see the same behavior even on a fresh verification app pinned to Node 20, this really does point to something going sideways at the platform/host-image level rather than in your code.

Here’s what you can try and check next:

1. Verify the exact Linux image your app is pulling • Run

   
        az functionapp show \
   
          --name <APP_NAME> \
   
          --resource-group <RG_NAME> \
   
          --query "siteConfig.linuxFxVersion"
   
   

   Make sure it’s exactly “Node|22” (or “Node|22-lts” depending on the portal output) • In Kudu (https://<APP_NAME>.scm.azurewebsites.net/Environment), note the WEBSITE_CONTAINER_START_TIME_LIMIT and any Docker image/digest info
2. Turn on more verbose host and worker logs • App Settings:
   • WEBSITE_LOGGING_FILE_SYSTEM = 1
   • FUNCTIONS_WORKER_RUNTIME_LOGGING__WORKER__GRPC = Trace
   • Then stream logs

   
        az webapp log tail \
   
          --name <APP_NAME> \
   
          --resource-group <RG_NAME>
   
   

   and look for any additional errors or gRPC handshake details
3. Compare platform versions In your host status JSON you saw "version":"4.1047.100.0", "platformVersion":"107.0.7.117" Let us know if other slots or apps on Node 22 (maybe in another region or plan) report a different platformVersion. It’ll help us rule in/out a bad image push or config regression.
4. Check your hosting plan and networking • Consumption vs. Premium vs. Dedicated? • Any VNet integration or custom DNS that might delay the worker startup?

Because you’ve already replicated it in a brand-new Node 20 app too, I’ll also loop in the Functions platform team to see if there was a bad image or recent change around 107.0.7.117.

In the meantime, can you share:

• The exact output of az functionapp show … --query siteConfig.linuxFxVersion for both the broken staging slot and the fresh verify app

• Confirmation of the plan tier and region you’re running in

• Any custom startup classes you’re injecting (if you’re using IWebJobsStartup) or if this is truly a vanilla “ping” function

• The full timestamped log tail from when you redeployed the verify app

With that info we can pinpoint if it’s a platform regression or a subtle config drift in your slots. Thanks for gathering those details – we’ll get to the bottom of it!

Thank you.

Thanks for your reply Monas!

Here are the additionally requested attributes.

• Main function app librarycontent-dedicated-functionapp: NODE|20 , platformVersion=107.0.7.117
• Staging slot librarycontent-dedicated-functionapp/staging: NODE|22 , platformVersion=107.0.7.117 (retrieved from Kudu in-container environment after the public /admin/host/status and slot key paths failed)
• Verification app librarycontent-node20-verify-0403175717: NODE|22, platformVersion=107.0.7.117

Timestamped verify-app redeploy log under Node 22

• Verification app was switched to NODE|22
• Same app.zip was redeployed
• Deployment ID: 178f6f75-9201-4ff0-aa97-cfe9e7a6e0cf

Timestamped deployment log:

2026-04-04T07:53:24.7382174Z  Updating submodules.
2026-04-04T07:53:27.2126158Z  Preparing deployment for commit id '178f6f75-9'.
2026-04-04T07:53:30.2015199Z  PreDeployment: context.CleanOutputPath False
2026-04-04T07:53:31.4375238Z  PreDeployment: context.OutputPath /home/site/wwwroot
2026-04-04T07:53:32.6740566Z  Generating deployment script.
2026-04-04T07:53:33.5272815Z  Running deployment command...
2026-04-04T07:57:07.0304472Z  Running post deployment command(s)...
2026-04-04T07:57:08.3592272Z  Triggering recycle (preview mode disabled).
2026-04-04T07:57:11.0280471Z  Deployment successful. deployer = az_cli_functions deploymentPath = Functions App ZipDeploy. Extract zip.

Plan tier and Region

• Region: East US
• Hosting plan: ASP-LibraryContentHandling-dedicated
• SKU: EP1
• Tier: ElasticPremium

Hello Blake Yarbrough,

Thank you for providing the additional details and the deployment logs. The information you shared is very helpful.

From what you’ve described, a few important observations stand out:

The main Function App running NODE|20 is operating normally.

The staging slot and the verification app both configured with NODE|22 are exhibiting the same startup failure.

All environments are reporting the same platformVersion: 107.0.7.117.

The deployment itself completes successfully via ZipDeploy, but the Functions host transitions to an Error state shortly after container startup, with the error indicating a gRPC timeout while building configuration in an external startup class.

Since you were able to reproduce the behavior in a fresh verification Function App with the same package, this does help narrow down the issue and suggests that it may not be related to the deployment package or CI pipeline itself. Instead, it could potentially be related to one of the following:

Runtime / host compatibility with Node 22 on the current platform build

A worker initialization delay or timeout during the Node worker gRPC handshake

An issue introduced in the Functions host version (4.1047.x) running on platform build 107.0.7.117

To help narrow this down further, could you please check and share the following:

1. Confirm the Functions runtime version

From the app settings or CLI:

az functionapp config appsettings list \

--name <APP_NAME> \

--resource-group <RG_NAME> \

--query "[?name=='FUNCTIONS_EXTENSION_VERSION']"

It should typically be set to: ~4

2. Verify the Node worker runtime

Please confirm the following settings for both the staging slot and the verification app:

FUNCTIONS_WORKER_RUNTIME = node

WEBSITE_NODE_DEFAULT_VERSION

3. Check host startup logs

If possible, please capture the host logs immediately after a restart:

az webapp log tail \

--name <APP_NAME> \

--resource-group <RG_NAME>

Look specifically for messages related to:

Worker process started

Starting language worker process

gRPC channel

Worker failed to initialize

4. Test with a minimal function

If you haven’t already, you may want to deploy a minimal HTTP trigger (for example a simple ping function) to the verification app under NODE|22 to confirm whether the failure occurs even without any dependencies.

Based on the consistent platformVersion (107.0.7.117) across your apps and the fact that the container exits shortly after startup, we will also check internally whether there are any recent platform updates or known regressions affecting the Node 22 worker on Elastic Premium plans in East US.