Issue with Blob Trigger Function Apps not listening for new blobs

Question

Issue with Blob Trigger Function Apps not listening for new blobs

• happens to multiple Function Apps
• multiple occurrences on multiple days
• Function Apps are on Consumption Plan (East US)
• logs show that the job host and listener are being stopped after 20-25 mins and remains inactive.  New blobs uploaded during this period are not processed.
• going to Azure Portal > Function App seems to re-initialize the Function App and then the listener "wakes up".   The delayed blob processing the immediately starts after this.

Answer 1

Hi @Matt Elman Matt Elman,

Thanks for the detailed report and for reaching out to Microsoft Q&A. The fact that you're seeing this across multiple Function Apps and on multiple days, with production blob processing getting delayed, makes this worth digging into properly rather than brushing off as a one-time glitch.

Based on what you're describing (host/listener stopping after ~20-25 minutes idle, staying inactive until you open the app in the Portal, then immediately catching up on the backlog), this lines up with known Consumption plan idle/scale-to-zero behavior rather than a mistake in your function configuration.

A couple of things worth knowing from the docs:

• The default Blob trigger relies on polling (a mix of log inspection and periodic container scans). The docs are explicit that on the Consumption plan, "there can be up to a 10-minute delay in processing new blobs if a function app has gone idle" (Blob storage trigger – Polling and latency).
• More broadly, Consumption plan apps can scale down to zero instances after a period of inactivity, which is documented as normal cold-start behavior (Event-driven scaling – Cold Start, Functions hosting options – Cold start behavior).

What you're seeing goes a bit beyond that documented 10-minute window, though — the listener isn't just delayed, it stays inactive until something manually forces the host to restart. I've seen the same pattern reported for other non-HTTP triggers on the Consumption plan (for example, a Service Bus trigger case here: Function app does not respond to Service Bus trigger after some period of inactivity), where the accepted answer attributes it to the platform scaling the app down and the listener not reliably restarting on its own when a new event arrives — manually refreshing in the Portal forces a cold start that reinitializes it, which matches exactly what you're describing.

A few options depending on what matters most for your scenario:

• If low-latency, reliable processing is the priority: consider switching from the default polling Blob trigger to the event-driven Blob trigger (set Source = EventGrid) or a Queue/Event Grid-based pattern instead. These don't depend on the container-scan/polling mechanism and aren't subject to the same idle-related delay — see the comparison table in Storage considerations – Trigger on a blob container.
• If you want to keep the classic Blob trigger: moving to a Premium plan (with always ready/prewarmed instances) or a Dedicated plan with Always On would stop the host from scaling to zero in the first place, which addresses the root cause of the listener stopping.
• Given this is recurring, affects multiple apps, and goes beyond the documented delay window, I'd also recommend opening a support case so engineering can look at the scale controller and host logs for your specific apps. This isn't something that's fully explained in public docs, so backend investigation is likely needed to confirm exactly why the listener isn't self-recovering within the expected window.

To help narrow it down further, it'd be useful to know: which Blob trigger source you're currently using (default polling vs. Event Grid), your host.json settings, and the Functions runtime/extension bundle version on these apps.

Hope this points you in the right direction!

Please 'Upvote' (Thumbs-up) and 'Accept' as answer if the response was helpful, as this will be benefitting other community members who face the same issue.

Best regards,

Andrew S Taylor

Answer 2

The host and listener stopping after 20–25 minutes is consistent with a Consumption app scaling to zero; that log alone is not a fault. However, Microsoft documents up to a 10-minute delay for the classic polling Blob trigger after an app becomes idle. Blobs remaining unprocessed until the portal is opened is not expected behavior.

Enable Application Insights and scale-controller logging, then correlate blob creation time with host shutdown, startup, and listener errors. Verify AzureWebJobsStorage and the trigger connection setting, storage firewall or private-endpoint access, and that the Storage Blobs extension is current.

For lower latency and reliability, change the binding to the Event Grid-based Blob trigger; alternatively use Premium or Dedicated with Always On. If several East US apps still reproduce after these checks, open Microsoft Support with UTC timestamps, app and storage resource IDs, runtime and extension versions, and scale-controller logs. Regional scale-controller investigation requires Microsoft platform telemetry.