Azure function app suddenly started showing Error text in Runtime version

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.

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:

1. 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].
2. 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.
3. 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:

• [1] Develop legacy C# class library functions using Azure Functions
• [2] Resolve "Function App Down or Reporting Errors" issues
• [3] Migrate C# apps from the in-process model to the isolated worker model