Azure Functions (.NET Isolated Custom Container) - Runtime Version "Error" and Function Host unavailable

Question

We are experiencing an issue with an Azure Function App hosted on Linux using a custom .NET Isolated container based on the image: mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated7.0-appservice.

The Function App is in a Running state, but the Azure Portal displays Runtime Version: Error, and the Sync Web Apps Function Triggers operation consistently fails with:

BadRequest - Encountered an error (ServiceUnavailable) from host runtime.

As a result, the Function Host does not initialize correctly and function triggers cannot be synchronized. We have already restarted the Function App, redeployed the application, and even reverted the Functions runtime version from v4 to v3, but the issue persists. We would like Microsoft to investigate why the Function Host is failing to start and why the runtime is reported as Error.

Answer 1

Hi @Ben Hmida, Syrine ,

I checked the base image mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated7.0-appservice, and it appears to be available, so this does not look like an image-not-found issue.

For a Linux custom container Function App, the next thing to check is whether the Function host is actually starting inside the deployed container. Please review the container/Docker startup logs from the SCM/Kudu site:

https://<function-app-name>.scm.azurewebsites.net

Look for errors such as host startup exceptions, missing files under /home/site/wwwroot, invalid or inaccessible AzureWebJobsStorage, FUNCTIONS_WORKER_RUNTIME mismatch, or port conflicts. If the host cannot start, the portal can show Runtime Version: Error, and trigger sync can fail with ServiceUnavailable.

Also, since this image targets .NET 7 isolated, it is worth testing/rebuilding with a supported Functions v4 isolated base image such as:

mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0-appservice

Please also confirm these app settings are present and valid:

FUNCTIONS_EXTENSION_VERSION=~4
FUNCTIONS_WORKER_RUNTIME=dotnet-isolated
AzureWebJobsStorage=<valid storage connection>
AzureWebJobsScriptRoot=/home/site/wwwroot

Reverting the Function runtime from v4 to v3 is unlikely to help here because the container image is based on the Functions v4 isolated runtime.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you. 

Answer 2

The symptoms indicate a runtime startup failure in the custom Linux container, not a deployment issue. Focus should be on container health, runtime configuration, and storage/runtime settings rather than redeploying or switching v3/v4.

Use the following steps to isolate and fix the issue:

1. Check container logs via Kudu
   For Linux custom containers, Runtime Version: Error and ServiceUnavailable often mean the container cannot start correctly.
   1. Browse to https://<FUNCTION_APP>.scm.azurewebsites.net for the Function App.
   2. Download the Docker logs .zip file.
   3. Inspect the logs for:
      • Exceptions during host startup.
      • manifest unknown or image pull errors (if the image tag is invalid).
      • Any indication that the Functions host process is failing to start.
   If the logs show manifest unknown, update the image reference using the Azure CLI as described in How to target Azure Functions runtime versions or fix/redeploy the custom image if using a private registry.
2. Verify the container image and ports
   For Linux container-based Function Apps:
   • Confirm the image mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated7.0-appservice is still valid and pulls successfully outside Azure (for example, in a local Docker environment).
   • Check the Docker logs for port binding errors. The Functions host in the container uses port :80 by default. If another process in the same image also binds to :80, the host will fail to start. In that case, adjust the image so only the Functions host uses port 80, or move other services to different ports.
3. Validate runtime and language configuration
   A misconfigured runtime or language version can prevent the host from starting:
   • Ensure FUNCTIONS_EXTENSION_VERSION is set correctly for v4 (for example, ~4) in Configuration → Application settings.
   • For Linux, confirm LinuxFxVersion is set to the correct <Language>|<LanguageVersion> for .NET isolated 7.0 as per the guidance in Using LinuxFxVersion for Linux Function Apps.
   • If the app was toggled between v3 and v4, verify that the image and LinuxFxVersion are consistent with the selected runtime and that no unsupported combination is configured.
4. Check storage account and configuration dependencies
   The Functions runtime will not start if it cannot access its storage account or required configuration:
   • Confirm the storage connection strings and any Key Vault references are valid and accessible, as described under common runtime issues after deployment.
   • If the storage account was changed or permissions modified, restore access and restart the Function App.
5. Run Function App diagnostics in the portal
   In the Azure portal:
   1. Open the Function App.
   2. Select Diagnose and solve problems.
   3. Run Function App Down or Reporting Errors (Preview).
   This workflow checks:
   • Startup issues and offline history.
   • Runtime and language version validity.
   • Configuration problems (mandatory app settings, Key Vault/Managed Identity, SyncTriggers, host name collisions).
   • Container allocation and resource issues.
   Use the findings to correct any flagged configuration or runtime mismatches.
6. Confirm this is a runtime (not deployment) issue
   Since the app is in Running state but the host is unavailable and Sync Web Apps Function Triggers fails with ServiceUnavailable, treat this as a runtime issue:
   • Files in wwwroot may be correct, but the host cannot start due to configuration, container, or dependency issues.
   • After addressing container errors, runtime version mismatches, and storage/configuration problems, restart the Function App and re-run Sync Web Apps Function Triggers.

If, after these steps, the container logs still show host startup failures with no obvious configuration or image issue, provide those specific log errors when opening a Microsoft support ticket so the runtime team can investigate why the host process is failing and why the runtime is reported as Error.

---

References:

• Troubleshoot error: "Azure Functions Runtime is unreachable"
• Resolve common runtime issues after deployment
• Troubleshoot common issues during Azure Runtime upgrade
• Resolve "Function App Down or Reporting Errors" issues