An Azure service that automates the access and use of data across clouds without writing code.
Thank you for reaching out to Microsoft Q&A.
Yes, this behavior can occur with Azure Logic Apps (Standard) that use the Azure Blob Storage built‑in trigger, and it is a known pattern rather than a capacity issue in most cases.
Based on the details you shared (low CPU/memory usage, WS2 plan with multiple instances, no connectivity errors), the delayed or non‑firing Blob triggers are typically caused by trigger architecture limitations and container scanning behavior, not by App Service Plan saturation.
In order to resolve this issue:
Narrow the Blob trigger scope (quick mitigation)
Configure the trigger with a specific folder path and file pattern, for example:
container/subfolder/{name}.csv
Avoid using the container root wherever possible.
This reduces listing and scan overhead.
Restart or re‑publish the Logic App (temporary workaround)
Restarting the Logic App can re‑initialize trigger listeners.
This often restores triggering temporarily but is not a long‑term fix.
Use Event Grid instead of Blob polling
For production systems with latency sensitivity, Microsoft recommends using an event‑driven architecture:
Configure Azure Blob Storage → Event Grid for BlobCreated events
Route events to:
Logic App with Event Grid trigger, or
Logic App HTTP trigger
Ref: https://learn.microsoft.com/azure/connectors/connectors-create-api-azureblobstorage