Isolated-worker Azure Functions app crashes with "Configuration is missing the 'HostEndpoint' information" when deployed as a classic WebJob — is this expected?

Question

Isolated-worker Azure Functions app crashes with "Configuration is missing the 'HostEndpoint' information" when deployed as a classic WebJob — is this expected?

Brijeshkumar Patel 0

We're migrating a console app from the classic Azure WebJobs SDK (Microsoft.Azure.WebJobs) to the Azure Functions isolated worker model (Microsoft.Azure.Functions.Worker, .NET 10, dotnet-isolated). The app has three queue-triggered functions ([Function("...")] with [QueueTrigger]).

Our current setup: we deployed the isolated-worker build using our existing classic-WebJob deployment convention — zipped to App_Data\jobs\continuous\<JobName>\ on a plain Azure App Service (Windows), the same way our other classic WebJobs are deployed on that same App Service (not a dedicated Function App resource).

Result — the process crashes immediately on startup:

System.InvalidOperationException: Configuration is missing the 'HostEndpoint' information. Please ensure an entry with the key 'Functions:Worker:HostEndpoint' is present in your configuration.
   at Microsoft.Extensions.DependencyInjection.GrpcServiceCollectionExtensions.GetFunctionsHostGrpcUri(IConfiguration configuration)
   at Microsoft.Extensions.DependencyInjection.GrpcServiceCollectionExtensions.GrpcWorkerStartupOptionsSetup.Configure(GrpcWorkerStartupOptions options)
   ...
   at Microsoft.Azure.Functions.Worker.Grpc.GrpcWorkerClientFactory..ctor(GrpcHostChannel outputChannel, IOptions`1 startupOptions)
   ...
   at DataSync.ContinuousWebJob.Program.Main()

The WebJobs runner treats this as a crash and auto-restarts the process every ~60 seconds, repeating the same failure indefinitely.

What we've already tried, without success:

Added <AzureFunctionsVersion>v4</AzureFunctionsVersion> to the .csproj — no change, identical crash.
Changed our build pipeline's ArchiveFiles step so the zip's root contains the published output directly (includeRootFolder: false) instead of nested under App_Data\jobs\continuous\<name>\, so the files land at the app root (wwwroot) rather than in the WebJob subfolder — still deployed via our existing "Azure App Service Deploy" task against the plain App Service, and the crash persists identically.
Confirmed local.settings.json isn't relevant here (it's a local-dev-only file, never deployed) and that none of its keys (AzureWebJobsStorage, FUNCTIONS_WORKER_RUNTIME, queue names) include Functions:Worker:HostEndpoint — so there's no setting we're aware of to add that would supply it.

Can an isolated-worker (dotnet-isolated) Azure Functions app run as a WebJob (classic WebJobs SDK-style deployment on a plain App Service), in any configuration — or does it strictly require a genuine Function App resource (kind: functionapp) to run at all?

Any pointer to official docs stating this explicitly would also help — most Functions docs assume a Function App resource from the start and don't call out this specific failure mode for a "wrong deployment target" scenario.

0 comments

2 answers

Your answer

Answer 1

Hi @Brijeshkumar Patel ,

You built a queue-triggered app on the Azure Functions isolated worker model (Microsoft.Azure.Functions.Worker, .NET 10), deployed it as a continuous WebJob under App_Data\jobs\continuous\<JobName>\ on a Windows Web App, and the process exits at startup with Configuration is missing the 'HostEndpoint' information. The exception is the expected outcome of that deployment, not a configuration gap you can close with a setting. The worker is a client process; it only does work when the Azure Functions host starts it and connects to it, and the WebJobs runner does not start a Functions host. No Learn page describes a supported way to run the isolated worker, or the Functions host, as a WebJob.

What the exception is telling you

In the isolated model, the executable you publish is not the Functions runtime. It is a gRPC client that the Functions host launches and then connects to. The value behind Functions:Worker:HostEndpoint is the gRPC address of that host. The worker would accept it from any configuration source (environment variables and command-line arguments are both registered), but in normal operation the host passes it on the command line as --functions-uri, together with --functions-request-id, --functions-worker-id, and --functions-grpc-max-message-length. The worker maps these switches to the Functions:Worker:* configuration keys in WorkerHostBuilderExtensions.RegisterCommandLine, and GrpcServiceCollectionExtensions.GetFunctionsHostGrpcUri throws exactly your exception when the key is absent.

Judging from your stack trace, DataSync.ContinuousWebJob.exe was started without those switches, which is what a WebJob deployment does unless a run script adds them, so the key is absent. Setting it yourself, for example as the app setting Functions__Worker__HostEndpoint, would only move the failure: there is no host listening at any address you could name, and nothing that would deliver a queue message to the worker. The 60-second restart loop is the documented PendingRestart state of a continuous WebJob that exits within two minutes of starting (WebJob statuses).

This is also why your second attempt did not change anything. Moving the payload from the WebJob folder to wwwroot puts the files where a Function App would expect them, but the identical crash shows that nothing on the Web App picked them up as a Functions payload; the Functions host is what a Function App resource provides, and only it launches the worker with those arguments.

The documented deployment target

The guide for the isolated worker model describes the deployment payload as the dotnet publish output, including functions.metadata, worker.config.json, extensions.json, and the .azurefunctions/ folder. These files are read by the Functions host, not by your executable; they are the host side of the contract. The same page lists deployment to Azure Functions only. No Learn page states the WebJob case as a failure mode, which matches your observation; the closest statements are the payload section and the comparison page below.

Since your other WebJobs already run on an App Service plan, the smallest change is to create a Function App resource in that same plan. The Dedicated plan documentation confirms that function apps run on the same App Service plan as web apps, billed with the plan rather than per execution. Deploy the existing publish output there, set FUNCTIONS_WORKER_RUNTIME to dotnet-isolated and netFrameworkVersion to your .NET version (the Windows settings listed under Deployment requirements), and enable Always On so the host does not idle between queue messages. Your queue functions and Program.cs need no changes for this move.

If the requirement is to stay on the Web App

The App Service feature that runs a background console process next to a web app is WebJobs with the WebJobs SDK, which your original code already used. The comparison page describes the WebJobs SDK as a console application that runs anywhere console applications run, and the WebJobs SDK tutorial (updated March 2026) still covers queue-triggered functions with Microsoft.Azure.WebJobs.Extensions 4.x and Microsoft.Azure.WebJobs.Extensions.Storage 5.x, verified there against .NET 8. Neither page carries a retirement notice for the WebJobs SDK. If the motivation for the switch was something other than the Functions host, keeping the WebJobs SDK project is the supported way to remain on a plain App Service. The Microsoft.Azure.WebJobs package (3.0.47 at the time of writing) targets .NET Standard 2.0, and NuGet lists net10.0 among the compatible frameworks, so the .NET 10 target itself is not the obstacle; the tutorial is verified against .NET 8 only, so the behavior of the complete package graph on .NET 10 is something to confirm in your own build.

References

Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against the Azure Functions .NET worker source on GitHub, the NuGet package page, and the Microsoft Learn pages listed above.

Answer 2

Yes. An Azure Functions app that uses the isolated worker model is expected to run under the Azure Functions host, not as a classic WebJob process on a plain App Service.

The failure is consistent with that mismatch:

The isolated worker model requires a Functions host/worker arrangement.
The worker expects host-provided configuration, including Functions:Worker:HostEndpoint.
If only the worker executable is started directly, that host-side configuration is missing, so startup fails with the HostEndpoint error.

The documented deployment model for isolated-worker Functions is Azure Functions, with these required platform settings:

FUNCTIONS_WORKER_RUNTIME=dotnet-isolated
On Windows, netFrameworkVersion set to the desired version
On Linux, linuxFxVersion set to the correct base image such as DOTNET-ISOLATED|8.0

Those are Function App runtime settings, not classic WebJob settings.

The deployment payload is also Functions-specific. The published output for isolated-worker deployment includes files such as:

.azurefunctions/
extensions.json
functions.metadata
host.json
worker.config.json
the project executable

That packaging is for Azure Functions deployment. The docs describe deploying to Azure Functions, not to App_Data\jobs\continuous\... as a WebJob.

The migration guidance also shows that moving from in-process/WebJobs-style packages to isolated worker requires code and project changes specific to Azure Functions:

remove Microsoft.Azure.WebJobs.* references
use Microsoft.Azure.Functions.Worker
add Program.cs for the isolated worker host
update function attributes to [Function]
set FUNCTIONS_WORKER_RUNTIME to dotnet-isolated

The troubleshooting guidance explicitly states that changing only settings or only code causes startup failure because isolated worker requires both application changes and platform configuration updates. It also lists missing Program.cs, wrong packages, and execution-model mismatch as common causes when an app fails to start after switching to dotnet-isolated.

So the practical conclusion is:

A dotnet-isolated Azure Functions app should be deployed to Azure Functions infrastructure.
Deploying that same build as a classic continuous WebJob on a plain App Service is not a supported runtime model in the provided documentation.
The repeated Functions:Worker:HostEndpoint crash is expected when the isolated worker is launched without the Azure Functions host.

If the goal is to keep running on plain App Service as a background process, the matching technology in the documentation is Azure WebJobs, which is a separate App Service feature for background tasks. If the goal is to run isolated-worker Functions, the target should be a real Function App resource with the required Functions runtime settings.

References: