Microsoft says Azure Failure Prediction and Detection, or AFPD, became fully operational in 2024 and now runs across parts of the Azure fleet to detect hardware risk before it interrupts workloads. The system uses machine learning and telemetry to identify failing nodes, move eligible virtual machines, and route hardware for repair. Microsoft says AFPD has improved prevention of hardware-related VM interruptions by 36%.
The change matters for teams running workloads where a host reboot is a business incident, not a routine platform event. SAP on Azure is the example Microsoft uses most directly, because SAP systems often hold finance, supply chain and operations data. Microsoft also says AFPD is not specific to SAP and operates across Azure Compute General Purpose, Specialized Compute, HPC/AI workloads and select Azure Storage scenarios.
How AFPD handles failing nodes
AFPD works in three phases. In the prediction and detection phase, models and detection rules monitor fleet telemetry, node behaviour, component signals and hardware indicators such as solid-state drive health. When the system identifies an active or likely future failure, it tags the node and starts the mitigation process.
During mitigation, Azure marks the node as not allocatable so new workloads do not land on it. Where the virtual machine is eligible, Azure live-migrates the workload to a healthy node without a reboot, usually with a pause of a few seconds. Live migration is available on many, but not all, M-series sized virtual machines.
Where live migration is not available, Azure posts a notification with a redeploy deadline and recommended action. Microsoft says these notifications appear in the VM’s Resource Health and Scheduled Events. Teams that already consume Scheduled Events need to confirm that their automation can handle NotBefore times up to seven days in the future.
The remediation phase takes the affected node out of production. AFPD attaches diagnostic detail so technicians do not repeat earlier troubleshooting, and Microsoft says spare parts are staged in advance to shorten repair time. Microsoft reports that AFPD has increased the monthly node repair rate by 80%.
Operational signals for customers
AFPD does not remove the need for workload design, high-availability configuration or operational response. It changes the point at which a team may receive the first usable signal. In some cases the platform has already moved the workload; in others, the customer must redeploy before the stated deadline.
Microsoft lists four customer-facing channels for AFPD findings. Resource Health shows detailed health events and recommended actions for individual virtual machines. Azure Resource Graph supports querying health status across larger estates, including SAP landscapes spread across subscriptions.
Event Grid can send AFPD events into customer automation, including Azure Functions, webhooks or REST APIs. Scheduled Events deliver advance VM event notifications through the Instance Metadata Service, which can be used by configured SAP high-availability clusters to move resources off affected nodes. Microsoft says the notification content is identical across Resource Health, Azure Resource Graph and Event Grid, so the choice is mainly about scale and integration.
For SAP high-availability clusters, Microsoft points to Pacemaker configuration for Azure Scheduled Events on SUSE Linux Enterprise Server and Red Hat Enterprise Linux in Azure. That is where AFPD becomes an operational dependency rather than a platform detail. If the cluster, monitoring and runbooks do not consume the signal, the additional warning may not reduce application impact.
Coverage and limits
AFPD builds on earlier Azure failure prediction work, including Project Narya. Microsoft says the system expands coverage to more hardware and software scenarios and adds scaled node repair to the prediction and mitigation work. The underlying paper on AFPD won the Best Paper Award at the 2025 IEEE Cloud Summit, according to Microsoft.
There are still boundaries for architects and administrators to check. Live migration eligibility depends on the VM shape and feature support. Azure Resource Graph and Event Grid endpoints for AFPD annotations are listed for Azure public cloud customers in Compute and HPC/AI, while non-public Azure offerings may differ.
Microsoft also describes VM Watch as a related diagnostic option for L-Series workloads. VM Watch is a lightweight in-VM watchdog service that emits health signals from guest virtual machines. Microsoft says enabling it for L-Series workloads is particularly relevant for AFPD prediction and detection.
AFPD should therefore be treated as part of a reliability design, not as a replacement for one. Teams still need zone and region choices, backup and restore tests, application failover patterns, and tested automation around platform events. The immediate work is to verify which AFPD channels are monitored and whether runbooks or cluster agents act on the events in time.
How AFPD changes failure handling for Azure VMs, and how teams wire Resource Health, Event Grid and Scheduled Events into operations, are practical questions in ECS's Infrastructure topic, alongside Azure architecture, hybrid cloud, cost and platform engineering. Sessions and workshops give attendees a place to compare platform behaviour, architecture choices and practitioner experience from production Azure estates. Bring the workload patterns and event-handling assumptions that need testing before they become incident procedures.
This article was written by the ECS editorial team with the assistance of Amal Agent, run.events' AI assistant, which supported the research, drafting and proofreading.