Firmware management alert rules not triggering on critical device failures after aziot-25 upgrade

IoT Microsoft Azure IoT
, , , , , , , ,
1

We upgraded our IoT Hub firmware management module to aziot-25 last week, and since then our critical device failure alerts have stopped triggering in Azure Monitor. The alert rules worked perfectly before the upgrade.

The issue appears related to event schema changes in aziot-25. Our alert rule mapping in Azure Monitor was configured for the old event format, and now the conditions aren’t matching. We also have firmware rollback automation that depends on these alerts to trigger remediation workflows.

Here’s our current alert rule query:


IoTHubEvents
| where EventType == "FirmwareUpdateFailed"
| where Severity == "Critical"

The query returns no results even though we can see failed firmware updates in the device logs. Has anyone else encountered this after upgrading to aziot-25? What changed in the event schema?

2

For the rollback automation dependency, you might want to consider implementing a fallback monitoring approach. We set up duplicate alert paths - one using the new schema and a temporary one that polls device twin reported properties directly. This gave us coverage while we migrated everything. The twin-based approach actually has lower latency for detecting failures in some cases. It’s worth exploring as a more resilient architecture even after you fix the primary alerts.

3

We had the exact same problem. The event schema definitely changed. In aziot-25, firmware events now use a different structure with properties like operationType and resultCode instead of the flat EventType field. You’ll need to update all your Azure Monitor queries to match the new schema. Microsoft should have documented this better in the release notes.

4

Here’s the complete solution for aziot-25 firmware alert migration:

Event Schema Changes: The aziot-25 release restructured firmware events significantly. The flat EventType property was replaced with a nested deviceUpdate object containing operationType, updateId, and resultDetails.

Updated Alert Rule Query:


IoTHubEvents
| where deviceUpdate.operationType == "firmwareUpdate"
| where deviceUpdate.resultDetails.status == "failed"
| where deviceUpdate.resultDetails.severity == "critical"

Alert Rule Mapping Steps:

  1. Navigate to Azure Monitor → Alerts → Alert Rules
  2. Locate your firmware failure rules (they’ll show 0 triggers since upgrade)
  3. Edit each rule and update the KQL query to use the new schema
  4. Update action groups if you’re parsing event properties in webhooks
  5. Test with a controlled firmware failure on a non-production device

Firmware Rollback Automation Dependency: This is critical. Your automation likely expects specific event properties in the alert payload. Update your rollback logic:


// Old property access
event.EventType, event.DeviceId, event.FirmwareVersion

// New property access
event.deviceUpdate.operationType
event.deviceId
event.deviceUpdate.updateId.version

Migration Strategy:

  1. Create new alert rules with aziot-25 schema (don’t delete old ones yet)
  2. Deploy updated rollback automation code that handles both schemas
  3. Test thoroughly in staging environment
  4. Monitor both old and new alerts in parallel for 48 hours
  5. Verify rollback automation triggers correctly
  6. Delete old alert rules once confident

Additional Considerations:

  • Action group webhook payloads changed format - update any consuming services
  • Alert description templates may need updates if they reference old properties
  • Consider implementing the device twin fallback monitoring that raj suggested for additional resilience
  • Document the new schema for your team to prevent future confusion

The key issue is that Azure Monitor alert rules don’t automatically migrate when IoT Hub event schemas change. You must manually update every affected rule. I recommend creating a test alert rule that fires on any firmware event to validate your new queries before updating production rules.

5

I ran into something similar last month. The aziot-25 release changed several event property names and added nested structures. Check if your EventType filter is still valid - they might have renamed it to something like FirmwareOperation with a status field.

6

Thanks for confirming. I found some documentation on the schema changes, but it’s incomplete. Does anyone have working queries for the new format? Also concerned about our rollback automation - it’s tightly coupled to these alert triggers.