Azure function app suddenly started showing Error text in Runtime version

Question

Azure function app suddenly started showing Error text in Runtime version

Abhijit Naik 0

My Azure function app suddenly started showing Error text in Runtime version. Azure function app is .Net 8 - In process model. When I am trying to test it using Postman it shows 503 SiteRoutedToIncorrectWorker - The service is unavailable.

We have not done any changes in the configuration or published the changes to function app.

Gursimran Singh 570 Reputation points Microsoft External Staff Moderator

2026-08-21T17:11:37.6533333+00:00
Hi @Abhijit Naik ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

The SiteRoutedToIncorrectWorker substatus (503) along with "Runtime version: Error" on the Overview page most commonly points to a mismatch in the app's.NET 8 in-process configuration, so we'd recommend starting there before treating this as a platform-side issue.

1. Verify the .NET 8 in-process settings for the in-process model on .NET 8, three settings must all agree:

FUNCTIONS_WORKER_RUNTIME = dotnet

FUNCTIONS_EXTENSION_VERSION = ~4

FUNCTIONS_INPROC_NET8_ENABLED = 1 — this is a dedicated setting required specifically for .NET 8 in-process, and its absence is the most common cause of this exact symptom (host fails to start with a mismatched worker, portal shows Runtime version as "Error").

Also check Configuration > General settings — the .NET version should read ".NET 8 (LTS), in-process model" (netFrameworkVersion = v8.0). If this and the app settings above are out of sync, the platform can allocate the site to an incorrect worker pool, producing the exact 503 you're seeing.

2. Check what may have changed the settings without a publish "No changes on our side" (code/deployment-wise) doesn't rule this out — app settings can change without a code push, e.g. via ARM/Bicep redeployment, Azure Policy remediation, or a manual portal edit. Please check the Activity Log for any Microsoft.Web/sites/config/write operations shortly before the issue started.

3. Stop and start the app (not just Restart) If the settings above are already correct, try a full Stop, then Start (rather than Restart) — this often clears a stale worker allocation, particularly on the Consumption plan where the platform reassigns workers on its own.

4. If the settings are correct and stop/start doesn't help

Run Diagnose and solve problems > "Function App Down or Reporting Errors" — this will show host start failures and any platform events during the failure window.

Check the Activity Log for the Function App and its App Service Plan for scale operations or auto-heal actions around the same time.

Confirm the linked storage account (AzureWebJobsStorage) is reachable, and its key/connection string hasn't rotated or been blocked — the host depends on this to initialize, and connectivity issues here also surface as "Runtime version: Error."

Check Resource Health (on the Function App) and subscription-level Service Health for any reported incidents in your region around the timestamp.

Separately, worth planning for: the in-process model (and .NET 8 support for it) reaches end of support on November 10, 2026. Regardless of the outcome here, we'd recommend planning a migration to the isolated worker model (.NET 8 or later) well before that date.

Please try the settings verification and stop/start first and let us know the outcome so we can proceed based on your findings.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Gursimran Singh 570 Reputation points Microsoft External Staff Moderator

2026-08-24T14:31:52.0233333+00:00

If the above steps did not help resolve your issue, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.
PB 0 Reputation points

2026-08-26T08:24:48.4166667+00:00

Hi @Abhijit Naik - we started seeing the same issue recently - 504/503 responses from Kudu. I think I finally found the cause of this. In our case the problem was happening right after deploying the function apps and hosting plan. I found out that when using hosting plan that is too small (B1) results in the CPU of the dedicated VM to be completely maxed out and therefore we were getting the 503/504. This is something that has gotten worse and has to do with Kudu/Azure, not with our code. Check the CPU usage of the App service VM if you're using a dedicated hosting plan.

1 answer

Your answer

Gursimran Singh 570 Reputation points Microsoft External Staff Moderator

2026-08-24T14:31:52.0233333+00:00

If the above steps did not help resolve your issue, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.
PB 0 Reputation points

2026-08-26T08:24:48.4166667+00:00

Hi @Abhijit Naik - we started seeing the same issue recently - 504/503 responses from Kudu. I think I finally found the cause of this. In our case the problem was happening right after deploying the function apps and hosting plan. I found out that when using hosting plan that is too small (B1) results in the CPU of the dedicated VM to be completely maxed out and therefore we were getting the 503/504. This is something that has gotten worse and has to do with Kudu/Azure, not with our code. Check the CPU usage of the App service VM if you're using a dedicated hosting plan.

Answer 1

Hi @Abhijit Naik ,

The substatus SiteRoutedToIncorrectWorker is not publicly documented, but its name and the symptom point to the routing layer. The frontend placed your site on a worker that does not match the app's configuration. That would also explain the "Error" in the Runtime version field, since the worker cannot start the host with the app's current settings.

For .NET 8 in-process, three settings must agree:

Environment variables: FUNCTIONS_WORKER_RUNTIME = dotnet, FUNCTIONS_EXTENSION_VERSION = ~4, and FUNCTIONS_INPROC_NET8_ENABLED = 1. The last one is required for .NET 8 in-process and is the most common cause when missing [1].
Configuration > General settings: the .NET version must read ".NET 8 (LTS), in-process model" (netFrameworkVersion = v8.0). If this and the environment variables disagree, the site can end up in the wrong worker pool.
Stop and start the app, not just Restart. In practice this often clears a stale allocation, particularly on the Consumption plan, where the platform reassigns workers on its own.

"No changes on our side" does not rule this out. Worker allocation is platform-side, and settings can change without a publish: ARM/Bicep redeployments, Azure Policy remediation, or a manual edit. Check the Activity Log for Microsoft.Web/sites/config/write operations shortly before the failures began.

If all settings are correct and stop/start does not help, run Diagnose and solve problems > "Function App Down or Reporting Errors" [2], check Azure Service Health for your region, and open a support ticket. With this substatus and no changes on your side, a platform-side issue is plausible.

Independent of the fix: the in-process model and .NET 8 both leave support on 10 November 2026, so plan the migration to the isolated worker model [3] soon regardless. I am publishing a step-by-step migration guide for this path (.NET 8 in-process to .NET 10 isolated) on my blog next week and will add the link here once it is live.

References:

Fabian 80 Reputation points

2026-08-23T08:21:50.6666667+00:00

@Abhijit Naik Did this resolve the issue on your side? If anything is still unclear or the behavior differs from what I described, let me know and I'll take another look.
Fabian 80 Reputation points

2026-08-25T11:56:54.7766667+00:00

As promised, the migration guide is published: .NET 10 in Azure: A Path Through Your Estate.

The Function Apps part is in step 6. It covers the project file changes, the minimal Program.cs, the IBinder and IAsyncCollector<T> removals, and the slot-based deployment that keeps FUNCTIONS_WORKER_RUNTIME and the code change in one operation.

One point relevant to this thread: the official migration guide still recommends .NET 8 as the isolated target, which lands you on a runtime that loses support on the same day as the in-process model. The article goes straight to .NET 10 and explains why.