Do not mistake resource-wide Failure Anomalies detection for per-API coverage

Source facts

Application Insights Failure Anomalies evaluates failure rates across the resource’s total requests, not independently for each API or application feeding it. After instrumentation, it needs sufficient data and a 24-hour learning period before alerting begins. Its machine-learning decisions are not fully deterministic. An alert’s analysis can identify characteristics such as operation, response code or application version, but those diagnostic details do not change the resource-wide detection scope. Microsoft Learn.

Applicability

Use this distinction when several applications or operations contribute to one resource, or when a service owner expects a specific API failure to produce a dedicated signal. Do not interpret a detailed operation name in an alert as proof that every operation has an independent detector.

DSE recommendation

Map critical API-level detection requirements separately from the resource-wide Failure Anomalies signal. Ask each service owner to define which operation-specific failures require attention and what observation would satisfy that requirement. Review the current telemetry grouping before relying on this detector for those commitments. Treat its diagnostic clusters as investigation leads, with user impact confirmed from the application’s own evidence.

Verification

Inspect the resource’s contributing applications and the actual scope of the alert rule. In an authorized test or retrospective review, compare an operation’s failure evidence with the overall resource signal. Record any uncovered requirement rather than claiming the absence of an anomaly proves API health. Include instrumentation and learning readiness in the review, and keep proposed supplemental checks distinct from tests already performed.

Official references

Microsoft Learn: Failure Anomalies smart detection. Source reviewed September 9, 2026.