Takeaway : Azure Failure Prediction and Detection (AFPD) is Microsoft Azure’s end-to-end system aiming to catch hardware failures before they interrupt a workload, not after. Across the Azure fleet, AFPD has improved the prevention of hardware-related VM interruptions by 36% . SAP workloads offer a compelling example of AFPD’s value, illustrating why preventing interruptions matters for mission-critical services.
But AFPD isn’t specific to SAP: it operates across General Purpose, Specialized Compute, HPC/AI, and select Storage workloads, making SAP’s experience a window into Azure’s broader approach to reliability for mission-critical third-party services. To learn more, watch our companion video to learn how AFPD helps reduce the risk of failures disrupting your critical workloads.
Reliability engineered into the platform Most conversations about cloud reliability focus on what you build: zone-redundant architectures, failover patterns, and backup strategies. Less visible, but just as consequential, is what the platform does on your behalf; before a failure ever becomes an incident you need to respond to. That’s the premise behind AFPD, which became fully operational in 2024.
AFPD is an end-to-end system that uses machine learning and telemetry to predict, mitigate, and remediate hardware failures in the Azure fleet before they interrupt your workloads. For a deep dive discussion into this capability, see the companion post here . How does AFPD predict and prevent hardware failures?
Historically, hardware failures on any cloud platform follow a familiar pattern: a component degrades, your workload is interrupted, an engineer investigates, and a reboot or hardware replacement follows. This is the old model Azure has spent years moving away from, one built around mission-critical escalations, supply chain constraints, and manual recovery.
AFPD replaces that pattern with three coordinated phases: Predict and detect : Machine learning models and detection rules continuously monitor telemetry across the Azure fleet, node behavior, component signals, and hardware-specific indicators like Solid State Drive (SSD) health, to catch patterns that indicate an active or likely future failure. Mitigate : Once a node is flagged, the mitigation service marks it not allocatable for new workloads and, where eligible, live-migrates existing customer workloads to a healthy node with no reboot, typically just a pause of a few seconds.
Live migration is available on many, but not all M-series sized virtual machines (VMs); check the feature support table for more information. Where live migration isn’t possible, a notification with a redeploy deadline and recommended action is posted to the VMs Resource Health and Scheduled Events. Remediate : The affected node is pulled from production, tagged with diagnostic detail so technicians can skip redundant troubleshooting, repaired using proactively staged spare parts, and returned to the fleet.
In practice, this coordinated approach has delivered measurable gains: AFPD has increased the monthly node repair rate by 80% . The result is a system that doesn’t just react faster; in many cases, it prevents the interruption from reaching you. This approach has reduced the overall number of hardware reboots by more than 36% , and the underlying system won the Best Paper Award at the 2025 IEEE Cloud Summit for its approach to predicting, mitigating, and remediating node interruptions at scale.
What SAP’s result means for other workloads Every customer benefits from fewer interruptions, but SAP workloads make the case for AFPD unusually clear. SAP systems are highly sensitive to downtime; they are often the system of record for finance, supply chain, and operations, and even brief interruptions carry outsized business impact. A platform that has the ability to predict or detect hardware issues and reduce their impact before you experience an interruption isn’t a convenience for SAP customers; it’s foundational to running SAP on Azure with confidence.
That sensitivity also exposed a real gap the team was candid about: many SAP customers aren’t yet aware of the notification and automation options available to them. AFPD surfaces its findings through four consistent, customer-facing channels: Resource Health , for viewing detailed health events and recommended actions on individual VMs, including live migration eligibility and redeployment deadlines.
Resource Graph Explorer , for querying health status across your fleet, including large SAP landscapes that require programmatic visibility. Event Grid , for wiring AFPD events directly into your own monitoring and automation, with Azure Functions , webhooks, or REST APIs. Scheduled Events , for receiving advance VM event notifications through IMDS, enabling configured SAP HA clusters to move resources off affected nodes.
The notification content is identical across Resource Health, Resource Graph, and Event Grid, so the channel you choose is a matter of scale and integration preference, not information quality. For SAP customers running at scale, that consistency is what makes automated, hands-off resiliency actually practical. It’s tempting to read AFPD as an SAP-specific feature.
It isn’t. SAP is simply where the stakes are high enough that the system’s value becomes obvious fastest. AFPD operates across Azure Compute’s General Purpose and Specialized Compute offerings, HPC/AI workloads, and select Storage scenarios, meaning the same predictive, self-healing infrastructure protecting SAP landscapes today is the same infrastructure underpinning every mission-critical third-party service hosted on Azure.
That’s the broader narrative worth taking away: AFPD isn’t a tier you pay up for or something you have to configure at the infrastructure layer; it runs automatically across the fleet.
Originally published at azure.microsoft.com
