Healthy app, no errors, no executions — check the storage account

The Azure Functions runtime depends on its associated storage account for trigger state, timer schedules, blob receipts, singleton locks, and function key storage. When that storage account becomes unreachable — a firewall rule, a private endpoint change, a rotated key — the app can appear healthy while triggers silently stop firing. It is one of the least obvious failure modes on the platform, because nothing in the application code references storage.

Azure Functions on an Elastic Premium plan with timer, blob, and queue triggers, in a subscription undergoing a network security tightening program. AceMQ works on the customer's function apps, configuration, and integration design — Microsoft operates the platform.

AceMQ started from the runtime's own dependencies rather than the application code, checking storage account reachability, the connection setting the runtime resolves, and the trigger state containers it maintains. Once connectivity was restored we rebuilt the monitoring around expected execution counts, since a failure-rate alert can never detect a trigger that never fires.

• 1
  Verified the runtime's storage account reachability, connection settings, and trigger state containers first
• 2
  Corrected storage firewall and private endpoint configuration to permit the function app's runtime access
• 3
  Separated the runtime's own storage account from application data storage so their policies diverge safely
• 4
  Replaced failure-rate alerting with expected-execution-count alerting per trigger
• 5
  Added a synthetic heartbeat function to prove the trigger path end to end
• 6
  Documented the runtime's storage dependency for the network team's change review process