Azure Monitor: OTP Verification Issue with Action Group Email Receivers — Persistent Failure

 Hello jgg671-9551,

Thank you for posting your query on Microsoft Q&A platform.

We understand that your Action Group email receiver OTP verification consistently fails after a successful delivery of the verification email, that usually points to a verification-code validation.

Your SubmitVerification observation is correct, and that's the key thing to settle first: the Azure Monitor action group email OTP is redeemed on a Microsoft-hosted verification page opened by the link in the verification email. There is no management.azure.com/.../verifyReceiver XHR in this flow, so its absence in your capture is expected you're on the supported path.

That reframes your evidence usefully. HTTP 200 OK with a rendered "Verification failed" body means the page served correctly and the verification service rejected the redemption at the application layer. That's a server-side outcome, not a browser or client problem.

On the OTP lifetime: the documented behavior is 30 minutes, not 10 "Email addresses must be verified through a one-time passcode (OTP) within 30 minutes of saving the action group… If the passcode expires, open the action group and select Resend." Since you entered each code promptly, expiry is not your cause.

Three more points that matter for your scenario:

• Verification is tenant-scoped and does not expire: once an address verifies anywhere in your tenant, it isn't asked again for other action groups there.
• Addresses configured before 23 July 2026 are grandfathered and unaffected.
• Removing and re-adding an address starts a fresh verification: so your remove/re-add test was valid, and its failure is meaningful rather than stale-state noise.

To answer your actual question: yes, this pattern has come up alongside the progressive regional rollout, and a service-side condition affecting the West US verification path in the window covering your 6 September onset is a credible lead. I won't overstate it that isn't confirmed as your root cause, and confirming it needs transaction-level correlation. What I can say is that your side is exhausted: config validated, receiver refreshed, fresh code, clean profile, prompt entry. There's nothing left for you to reconfigure.

Three things worth doing:

1. Read the receiver's actual verification state. Portal > action group > JSON View, API version 2026-03-01-preview, so emailReceivers[] exposes status (Verified / VerificationPending / LegacyAllowed). Verify: the affected receiver shows a status field. No field = the API version didn't apply. Why: separates "the redemption never committed" from "it committed and the portal is stale" different causes entirely.
2. Capture one clean failing transaction. Record the exact UTC timestamp (to the second), the correlation / request / activity ID from the response headers, and the sanitized request path. Keep withholding the OTP, signed payload, tokenized URL parameters, cookies, and session material you're right to, and none of it is needed to trace this server-side. Verify: you hold a correlation ID and a timestamp from the same attempt. Why: this is what lets the product team isolate your specific transaction and read the backend rejection reason instead of inferring it from a time window. Highest-value item you can produce.
3. Rule out session-context loss it's a five-minute test. Redeem once in a single ordinary (non-InPrivate) browser session, no proxy or TLS-inspection hop between reading the mail and submitting the code. Verify: same error = session continuity ruled out, fault is server-side. Success = your redemption path is sensitive to session context. Why: in comparable Microsoft OTP flows a valid, in-window code is rejected when the redeeming session isn't the one that requested it, usually because cookies were dropped or rewritten in transit.

On a workaround: there is no self-serve bypass. Through your existing support case, the product team can mark the address as verified on the backend manual, per-address. That will deploy your emergency-access control, but it's a workaround, not a fix: it doesn't repair the redemption failure. Ask for it in parallel with the escalation, not instead of it.

References

• Action groups - Notification types https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups#notification-types the 30-minute OTP window, the Resend path, tenant-wide persistence, and the rule that an unverified receiver can't receive alert or test notifications once enforcement is active.

Thanks