Per function host config

[marcobaldo]

I have grouped several functions (with service bus topic triggers) into one function app, but I need some of the functions to have different maxConcurrentCalls settings (among other settings). Is it possible to have separate host configs per function?

Repro steps

Provide the steps required to reproduce the problem

1. Create function 1, doesn't require maxConcurrentCalls to be set (so uses default value)

2. Create function 2, but requires a different maxConcurrentCalls value

Expected behavior

Be able to set the maxConcurrentCalls settings (among other settings) per function

Actual behavior

Settings are defined globally in host.json

Known workarounds

Related information

[mathewc]

Yes, I agree this would be good to have. The underlying SDK does support both host level as well as queue level configuration (not per function) but we don't currently expose that in Functions. The reason is that in the underlying C# SDK, this is done by registering factories to return message processors based on paths (see QueueProcessorFactory for Storage Queues and MessagingProvider for ServiceBus).

So that doesn't map directly to Functions since it is queue/path based, not per function. We'll need to think on it more.

[pauleharris]

+1 descrite execution, but grouped config gets you only half way there

[johnib]

This is a must have. Wondering what's the status of this

[paulbatum]

No status updates at this time. I think customers that find they need this capability are creating multiple function apps with different configuration. Obviously this is not a great solution because it makes deployments more complicated. So the issue remains open, but we have many issues with higher priority so there is no ETA.

[stap123]

@paulbatum Any updates on this now V2 is out the door?

Would be great to be able to have a different maxPollingInterval set for individual functions. Some are more critical than others and obviously the polling interval is a big factor in cost in relation to queue triggered functions.

[paulbatum]

Unfortunately the status is unchanged and I am not able to provide an ETA. We continue to recommend the workaround I mentioned above.

[bhokareprasad]

Any update on this? This feature has enormous value for adding short term and silent background jobs which can be pushed through existing deployment rather than getting new deployment each time.(Which is obviously very lengthy process to go through)

[MichaMican]

Any updates? It has been 5 Years, maybe the backlog cleared up a bit 😄

/cc @paulbatum

[samfromlv]

So this is a blocker. We are trying to slowly migrate from Quartz.net based scheduler application to Azure Functions. However creating separate applications for every Azure Queue function is not an option too much overhead. Putting all functions in the same app is also not an option, we will be limited by a single function with the lowest supported concurrency. In our case one of the queue functions is using an external API with low quotas and even 3 concurrent requests to this API will produce HTTP 429, so we have to limit concurrency.

Please find time to implement this.

[jonathanford]

Would like to see this added so that MaxConcurrentSessions can be configured per function.

It would provide a lot more flexibility instead of needing to make tradeoffs in how many messages can be processed concurrently.

[DieterGobeyn]

I fully agree that we need more fine-grained control for performance tuning at the function level rather than only at the function app level. This i useful for patterns like the priority queue, where certain functions need stricter concurrency limits.

While .NET apps allow creating multiple RegisterMessageHandlers for more advanced scenarios, unfortunately Azure Functions does not expose that flexibility. This limitation forces us to split logic across multiple function apps, which adds deployment complexity and overhead.

Having per-function (not per app) control would offer better cost efficiency and reduce the amount of projects we need to maintain.