Thanks for the follow-up. You're right — service health notifications and App Service Health Checks don’t apply to function apps running on the Linux Consumption Plan, which does limit some proactive monitoring options.
Here are a few things we can consider as alternatives:
- Monitoring: We can enable Application Insights and set up alerts based on log inactivity or failures. For example, if the blob trigger hasn’t logged any activity for a set time, we get notified.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-monitoring?tabs=cmd - Warm-up Trigger: Since blob triggers can’t be called directly, we can add a lightweight timer-triggered function in the same app. This runs periodically (say every 5 minutes) just to keep the function app warm and reduce cold start issues.
https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=in-process%2Cnodejs-v3%2Cv1-model&pivots=csharp#monitoring - Auto Healing (New Diagnostics Experience): App Service now supports an Auto Healing feature via App Service Diagnostics, which can take predefined actions (like restarting the app) if unhealthy conditions are detected — though this is more relevant for App Services and Premium plans. Announcing Auto Healing in App Service Diagnostics
- Scaling: Consumption Plan does support auto-scaling, but there can be occasional delays if the scale controller is busy, or in rare cases, platform-level issues. Adding retries or fallback logic where possible can help here.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-blob-trigger?tabs=python-v2%2Cin-process%2Cnodejs-v4%2Cextensionv5&pivots=programming-language-powershell#trigger-behavior
If this function app is business-critical, we might also want to consider switching to the Premium Plan, which offers better reliability, warm instances, and more control.