Azure Functions Flex Consumption (.NET 10 isolated): Storage Queue trigger discovered by host but never scales from zero

Question

Azure Functions Flex Consumption (.NET 10 isolated): Storage Queue trigger discovered by host but never scales from zero

Mike Hudgell - Lead Volunteer 0

I have referred to https://learn.microsoft.com/en-ca/answers/questions/5934284/flex-consumption-net-8-isolated-storage-queue-trig which doesn't really say anything useful other than "it may work... if not open a support ticket", but I'm getting asked to create here first

I’m investigating what appears to be a trigger-metadata / scale-controller issue with an Azure Functions Flex Consumption application, and would appreciate guidance on how to diagnose or correct it without configuring an always-ready instance.

Environment

Azure Functions Flex Consumption, Linux
.NET 10 isolated worker
512 MB instances, maximum 10 instances
Azure Storage Queue trigger
Identity-based Storage connection / managed identity
Storage account accessed using private networking
Function App uses VNet integration
Infrastructure deployed using Bicep via Azure DevOps
No always-ready instances configured

The ingress Function App contains three functions:

GraphMailWebhook                 HTTP trigger
MaintainGraphMailSubscription    Timer trigger
ProcessGraphMailNotification     Azure Storage Queue trigger

The intended flow is:

Microsoft Graph
      |
      v
GraphMailWebhook
      |
      v
graph-mail-notifications Storage Queue
      |
      v
ProcessGraphMailNotification

The HTTP Graph webhook works. For example:

POST api/graph/notifications
result=202
success=True

The Functions host also clearly discovers the queue-triggered function:

Found the following functions:
Host.Functions.GraphMailWebhook
Host.Functions.MaintainGraphMailSubscription
Host.Functions.ProcessGraphMailNotification

and the queue extension starts with:

QueuesOptions
{
  "BatchSize": 8,
  "NewBatchThreshold": 4,
  "MaxPollingInterval": "00:01:00",
  "MaxDequeueCount": 5,
  "VisibilityTimeout": "00:01:00",
  "MessageEncoding": "Base64"
}

However, after the HTTP invocation the only Flex function group I see instantiated is:

Function group target is http

I never see a corresponding:

function:ProcessGraphMailNotification

and ProcessGraphMailNotification does not execute.

There are no current startup errors or queue-trigger function exceptions in the logs.

Things already checked

RBAC has been deliberately scoped tightly rather than giving the Function App broad Storage Contributor rights. The ingress managed identity has the appropriate Storage Queue data-plane permissions on the exact queue, including Storage Queue Data Message Processor.

The producer/consumer message encoding has also been made explicitly Base64 at both ends. We previously had an encoding mismatch which caused messages to reach MaxDequeueCount; that behaviour has now disappeared.

We also checked the actual deployed Flex configuration using ARM:

{
  "alwaysReady": 
  "instanceMemoryMB": 
  "maximumInstanceCount": 
  "triggers": 
}

This is important because I found another Microsoft Q&A report where the same symptom was caused by:

"triggers"

instead of null. That is not the case here.

I also do not want to solve this by permanently configuring an always-ready instance. My understanding is that Flex Consumption supports event-driven scale-to-zero for non-HTTP functions, and always-ready should be an optional cold-start optimisation rather than a requirement for a Storage Queue trigger to function.

Trigger resync

I am now testing an explicit trigger metadata resync using:

az

The REST API documentation describes this operation as synchronising function trigger metadata to the management database.

Questions

In Flex Consumption, should ProcessGraphMailNotification normally cause a function:ProcessGraphMailNotification scale group to be created from zero when a Storage Queue message arrives, with no always-ready configuration?
Is an explicit syncfunctiontriggers call expected or recommended after deploying a Flex Function App using private networking/VNet integration?
Is there a supported way to inspect the trigger metadata that the Flex scale controller currently has registered for the Function App? The runtime host clearly knows about the function, but I would like to establish whether the scale controller does.
If syncfunctiontriggers fixes this, should that operation be incorporated explicitly into an Azure DevOps deployment pipeline, or should a normal Functions deployment already perform this automatically?
Are there known issues around trigger synchronisation when a Flex Function App uses VNet integration/private endpoints which could leave HTTP functions operational while non-HTTP scale-from-zero triggers are not registered correctly?

I’m particularly interested in identifying the underlying configuration/deployment issue rather than using an always-ready instance to mask it, as maintaining continuously allocated compute would undermine the reason for using Flex Consumption for this relatively low-volume workload.

I can provide the Bicep for the Function ApI’m investigating what appears to be a trigger-metadata / scale-controller issue with an Azure Functions Flex Consumption application, and would appreciate guidance on how to diagnose or correct it without configuring an always-ready instance.

Environment

Azure Functions Flex Consumption, Linux
.NET 10 isolated worker
512 MB instances, maximum 10 instances
Azure Storage Queue trigger
Identity-based Storage connection / managed identity
Storage account accessed using private networking
Function App uses VNet integration
Infrastructure deployed using Bicep via Azure DevOps
No always-ready instances configured

The ingress Function App contains three functions:

GraphMailWebhook                 HTTP trigger
MaintainGraphMailSubscription    Timer trigger
ProcessGraphMailNotification     Azure Storage Queue trigger

The intended flow is:

Microsoft Graph
      |
      v
GraphMailWebhook
      |
      v
graph-mail-notifications Storage Queue
      |
      v
ProcessGraphMailNotification

The HTTP Graph webhook works. For example:

POST api/graph/notifications
result=202
success=True

The Functions host also clearly discovers the queue-triggered function:

Found the following functions:
Host.Functions.GraphMailWebhook
Host.Functions.MaintainGraphMailSubscription
Host.Functions.ProcessGraphMailNotification

and the queue extension starts with:

QueuesOptions
{
  "BatchSize": 8,
  "NewBatchThreshold": 4,
  "MaxPollingInterval": "00:01:00",
  "MaxDequeueCount": 5,
  "VisibilityTimeout": "00:01:00",
  "MessageEncoding": "Base64"
}

However, after the HTTP invocation the only Flex function group I see instantiated is:

Function group target is http

I never see a corresponding:

function:ProcessGraphMailNotification

and ProcessGraphMailNotification does not execute.

There are no current startup errors or queue-trigger function exceptions in the logs.

Things already checked

RBAC has been deliberately scoped tightly rather than giving the Function App broad Storage Contributor rights. The ingress managed identity has the appropriate Storage Queue data-plane permissions on the exact queue, including Storage Queue Data Message Processor.

The producer/consumer message encoding has also been made explicitly Base64 at both ends. We previously had an encoding mismatch which caused messages to reach MaxDequeueCount; that behaviour has now disappeared.

We also checked the actual deployed Flex configuration using ARM:

{
  "alwaysReady": 
  "instanceMemoryMB": 
  "maximumInstanceCount": 
  "triggers": 
}

This is important because I found another Microsoft Q&A report where the same symptom was caused by:

"triggers"

instead of null. That is not the case here.

I also do not want to solve this by permanently configuring an always-ready instance. My understanding is that Flex Consumption supports event-driven scale-to-zero for non-HTTP functions, and always-ready should be an optional cold-start optimisation rather than a requirement for a Storage Queue trigger to function.

The call succeeds and causes the app/host to reload its function metadata, but the queue function still does not execute. Following the sync, telemetry again shows ProcessGraphMailNotification being discovered, but no queue-trigger invocation occurs.

During host recycling I can see:

ProcessGraphMailNotification Stopping the listener ...
ProcessGraphMailNotification Stopped the listener ...
DrainMode mode enabled

After the subsequent host startup the function is discovered again, but still doesn't consume the queue.

There is no current exception, binding failure or authorization error in the Function App logs.

Expected behaviour

My understanding of Flex Consumption per-function scaling is that a Storage Queue function should scale independently as:

function:ProcessGraphMailNotification

and should not require an always-ready instance merely to consume a queue.

Questions

1. Is there any additional trigger-registration step required for a Storage Queue trigger on Flex Consumption when the queue is behind a private endpoint and the app uses managed identity?
Is there a way to inspect the trigger metadata registered with the Flex scale controller, rather than just the metadata seen by the running Functions host?
Is there specific scale-controller telemetry available to show why function:ProcessGraphMailNotification is not being instantiated?
Is an always-ready instance expected/required for this combination, or should normal event-driven scale-from-zero work?
1. Are there any known current issues involving Flex Consumption + Storage Queue triggers + private endpoints/managed identity? I'm specifically trying to avoid using an always-ready instance as a workaround because that defeats part of the serverless cost model for a low-volume workload.

I can provide the Bicep for the Function App

Lakshma Reddy Vattijonnala 1,495 Reputation points Microsoft External Staff Moderator

2026-08-16T21:51:38.5666667+00:00

Hi @Mike Hudgell - Lead Volunteer Thank you for reaching out to Microsoft Q&A. We are looking into the issue and we will get back to you shortly with an update
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-08-17T06:28:24.0733333+00:00
Hi @Mike Hudgell - Lead Volunteer

Please provide me the details I have asked in Private message on this question to check your issue from backend?

Also, Refer below steps while you send me the details on message:

Based on the information provided, this behavior is not expected in Azure Functions Flex Consumption. A Storage Queue trigger should automatically scale from zero and create its own scale group (function:ProcessGraphMailNotification) when messages arrive in the queue. Since the Function Host successfully discovers the function, no startup, binding, or authorization errors are reported, and manual trigger synchronization does not resolve the issue, the problem appears to be related to trigger registration or scale-controller recognition rather than the application code itself. Azure Functions Flex Consumption plan hosting and Event-driven scaling in Azure Functions confirm that queue-triggered functions support independent event-driven scaling without requiring Always Ready instances

Refer below points to resolve this issue or as a workaround:

Verify Managed Identity and Queue Configuration

Ensure the Function App identity has the required queue permissions and that the identity-based connection settings are configured correctly.

GraphMailQueue__queueServiceUri=https://<storageaccount>.queue.core.windows.net

2. Validate Private Endpoint and DNS Resolution

Confirm that the Function App can resolve and access the queue endpoint through the VNet integration.

Verify privatelink.queue.core.windows.net DNS zone.

Verify VNet links and private endpoint resolution.

Check NSG/UDR rules.

Networking issues can prevent queue-trigger scale operations

3. Trigger Synchronization is Normally Automatic

A normal Flex Consumption deployment should automatically synchronize triggers. Manual execution of syncfunctiontriggers is useful for diagnostics but should not be required as part of regular deployments.

az rest --method post \ --url "https://management.azure.com/.../syncfunctiontriggers?api-version=2023-12-01"

Since sync did not resolve the issue, the root cause is likely elsewhere.

4. Always Ready Should Not Be Required

Always Ready instances are intended only to reduce cold-start latency. Storage Queue triggers should scale from zero without Always Ready configuration. If enabling Always Ready makes the function work, it may be masking an underlying scale-controller or trigger-registration issue.
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-08-18T06:32:35.3233333+00:00

Hi @Mike Hudgell - Lead Volunteer

I have raised a ticket internally to address your issue with the product team and have emailed you as well. I will keep you updated on the status from Product team on your issue.
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-08-19T07:54:59.5266667+00:00

Hi @Mike Hudgell - Lead Volunteer

Can you please perform the recommended mitigation provided by the product team and inform me?

Leading root cause

The Function App managed identity has the Storage Queue Data Message Processor role. This role permits reading and processing queue messages, but it does not include the permission needed to read queue properties and determine the approximate message count.

The Scale Controller must read the queue message count before it knows that a worker is needed. If this metadata request receives a 403, the current scaler implementation silently treats the queue length as zero. As a result, no worker starts even though a message is waiting

Recommended mitigation

Add Storage Queue Data Reader to the ingress managed identity at the exact graph-mail-notifications queue scope. Keep the existing Storage Queue Data Message Processor role.

No always-ready instance, redeployment, restart, or explicit trigger synchronization should be required. Allow several minutes for RBAC propagation, then repeat the controlled Graph notification test.

Thanks and Regards,

Siddhesh Desai
Allan Solomon Mejia 6,240 Reputation points

2026-08-19T15:52:43.3066667+00:00

Hello @Mike Hudgell - Lead Volunteer

Please let us know if you need any further assistance. Otherwise, if the information provided resolved your issue, please click “Accept Answer” to help others who may encounter the same problem.

Thank you!
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-08-25T10:33:10.02+00:00

Hi @Mike Hudgell - Lead Volunteer

I have got below response from the backend product team:

In Flex Consumption, should ProcessGraphMailNotification normally cause a function:ProcessGraphMailNotification scale group to be created from zero when a Storage Queue message arrives, with no always-ready configuration?

-- Yes, the function group will be created and is expected to scale from zero, even with no always ready and vnet

Is an explicit syncfunctiontriggers call expected or recommended after deploying a Flex Function App using private networking/VNet integration?

-- It is expected, although not manually from the user. It is done after every deployment.

Is there a supported way to inspect the trigger metadata that the Flex scale controller currently has registered for the Function App? The runtime host clearly knows about the function, but I would like to establish whether the scale controller does.

-- From the scaling side, I do not think this is information that is exposed to customer.

If syncfunctiontriggers fixes this, should that operation be incorporated explicitly into an Azure DevOps deployment pipeline, or should a normal Functions deployment already perform this automatically?

-- It is done in deployment already; it need not be performed by the cx.

Are there known issues around trigger synchronisation when a Flex Function App uses VNet integration/private endpoints which could leave HTTP functions operational while non-HTTP scale-from-zero triggers are not registered correctly?

-- Not any longstanding issues that I'm aware of. If any, there is a possibility of transient errors.

The backend team has asked below questions:

Were you always facing scaling errors with their queue function? or was there a starting point before which the scaling was working fine?

have you tried removing the vnet and testing scaling to narrow down if the issue is because of vnet or the queue trigger configuration?
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-08-27T07:30:15.1966667+00:00

Hi @Mike Hudgell - Lead Volunteer

Did you get chance to check my previous response?

1 answer

Your answer

Lakshma Reddy Vattijonnala 1,495 Reputation points Microsoft External Staff Moderator

2026-08-16T21:51:38.5666667+00:00

Hi @Mike Hudgell - Lead Volunteer Thank you for reaching out to Microsoft Q&A. We are looking into the issue and we will get back to you shortly with an update
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-08-18T06:32:35.3233333+00:00

Hi @Mike Hudgell - Lead Volunteer

I have raised a ticket internally to address your issue with the product team and have emailed you as well. I will keep you updated on the status from Product team on your issue.
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-08-19T07:54:59.5266667+00:00

Hi @Mike Hudgell - Lead Volunteer

Can you please perform the recommended mitigation provided by the product team and inform me?

Leading root cause

The Function App managed identity has the Storage Queue Data Message Processor role. This role permits reading and processing queue messages, but it does not include the permission needed to read queue properties and determine the approximate message count.

The Scale Controller must read the queue message count before it knows that a worker is needed. If this metadata request receives a 403, the current scaler implementation silently treats the queue length as zero. As a result, no worker starts even though a message is waiting

Recommended mitigation

Add Storage Queue Data Reader to the ingress managed identity at the exact graph-mail-notifications queue scope. Keep the existing Storage Queue Data Message Processor role.

No always-ready instance, redeployment, restart, or explicit trigger synchronization should be required. Allow several minutes for RBAC propagation, then repeat the controlled Graph notification test.

Thanks and Regards,

Siddhesh Desai
Allan Solomon Mejia 6,240 Reputation points

2026-08-19T15:52:43.3066667+00:00

Hello @Mike Hudgell - Lead Volunteer

Please let us know if you need any further assistance. Otherwise, if the information provided resolved your issue, please click “Accept Answer” to help others who may encounter the same problem.

Thank you!
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-08-27T07:30:15.1966667+00:00

Hi @Mike Hudgell - Lead Volunteer

Did you get chance to check my previous response?

Answer 1

Hello @Mike Hudgell - Lead Volunteer

Your expectation is correct: on Flex Consumption, a Storage Queue-triggered function should be able to scale independently from zero. Always-ready instances default to zero and are intended to reduce cold-start latency; they are not a requirement for queue processing. Microsoft also documents that non-HTTP triggers generally receive their own per-function scale group in Flex Consumption.

Given your evidence, I would separate host discovery from scale-controller registration. The Functions host clearly discovers ProcessGraphMailNotification, but that alone does not prove that the Flex scale controller has usable trigger metadata for scaling that function from zero.

A few points:

syncfunctiontriggers should not normally be required after every standard Functions deployment. Trigger synchronization is part of normal deployment behavior. Microsoft documents manual trigger synchronization for specific deployment models, such as when the app references a package whose contents are changed without changing its URL.
Since you've already run a trigger sync successfully and the host rediscovered the queue function, but the queue still isn't consumed, I would not add syncfunctiontriggers blindly to the Azure DevOps pipeline yet. That risks masking the real issue.
Enable verbose scale-controller telemetry:

az functionapp config appsettings set \
  --name <FUNCTION_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose

Microsoft documents this specifically for sending detailed scale-controller decisions to Application Insights.

That telemetry is probably the most useful next step because it can show whether the scale controller is seeing the queue trigger and why it is, or is not requesting an instance.

I would also concentrate on the private Storage path. Your running instance can access the queue through VNet integration, but scale-from-zero requires the platform's trigger-scaling machinery to correctly monitor the event source. Flex Consumption supports VNet integration, managed identities, and dynamic scaling to zero, so this combination should be supported in principle.

At this point, because:

the host discovers the queue function,
RBAC and Base64 handling have already been checked,
trigger synchronization completes,
there are no binding/startup exceptions,
no function:ProcessGraphMailNotification scale group appears, and
the trigger still fails only when relying on scale-from-zero,

I think this is strong enough to justify an Azure Functions backend investigation, especially around the trigger metadata/scale-controller path for the private Storage endpoint.

I wouldn't recommend configuring an always-ready instance as the permanent fix. It would be useful only as a diagnostic A/B test: if function:ProcessGraphMailNotification = 1 immediately makes queue processing work, that would strongly suggest the runtime binding itself is healthy and the failure is specifically in scale-from-zero detection/activation.

For escalation, collect the Function App resource ID, Storage account/queue name, exact UTC timestamps when messages were present, Application Insights scale-controller logs, trigger-sync timestamp/result, and the current Flex configuration.

Sharing you these references:

Microsoft Learn – Flex Consumption plan and always-ready instances.

https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-plan?

Microsoft Learn – Event-driven/per-function scaling.

https://learn.microsoft.com/en-us/azure/azure-functions/event-driven-scaling?

Microsoft Learn – Functions deployment and trigger synchronization.

https://learn.microsoft.com/en-us/azure/azure-functions/functions-deployment-technologies?

Microsoft Learn – Scale-controller logging.

https://learn.microsoft.com/en-us/azure/azure-functions/configure-monitoring?

I would frame this as “host metadata is healthy, but Flex scale-from-zero activation for the private queue trigger appears not to be occurring” rather than as a confirmed .NET 10 issue.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Mike Hudgell - Lead Volunteer 0 Reputation points

2026-08-19T21:00:08.42+00:00

I have provided more info in the Private Messages, waiting on MSFT support