How does action group handle alert retries

Question

I want to know how does Action Group handle retries(whether it retires or not, and if it does what are the details). In my case I want will be using Events Hub which will be directly connected to the Action Group. Now when the Event Hub is down for whatver reason what is the logic of retrying alerts.

Answer 1

VERMA VedantFRJP:IT Infrastructure

action groups do retry, but it is not infinite and not something u can tune directly 😄 for Event Hub specifically Azure Monitor will try delivery with built-in retry + backoff, but if Event Hub is unavailable long enough the notification is dropped, there is no guaranteed delivery or durable queue in Action Group itself. think of it as best-effort push, not message broker. retries are short-lived (minutes range), not hours, and no replay once it gives up.

important nuance for Event Hub receiver if the namespace is reachable but throttling/partial failure happens, retries usually succeed, if the endpoint is fully down or auth fails, retries will exhaust quickly. there is no dead-letter or retry queue u can access from Action Group side.

if u need reliability, recommended pattern is not direct Action Group > Event Hub, but insert something durable:

• Action Group > Logic App > retry policy + queue
• or Action Group > Event Grid > Event Hub (Event Grid has better delivery guarantees and retry window)

monitor Action Group delivery failures via Activity Log / alert processing logs, because failures are not always obvious.

rgds, Alex

&

if my answer helps pls accept it.

Answer 2

Hello VERMA VedantFRJP:IT Infrastructure,

Thank you for reaching out to the Microsoft Q&A forum. 

When investigated here’s how Action Groups handle retries when calling an external endpoint like Event Hubs:

1. Automatic retries on transient failures
   • When an alert fires, Azure Monitor calls the Event Hubs endpoint under the covers of the Action Group.
   • If that call fails with a retryable error (HTTP 408, 429, 503, 504 or network exceptions like HttpRequestException, WebException, TaskCancellationException), it will automatically retry.
2. Retry count and backoff
   • Azure Monitor will make the initial call plus up to 5 retries (so 6 attempts total).
   • It uses exponential backoff between retries, capped at 5 seconds. For example, you’ll see increasing delays between the 1st→2nd, 2nd→3rd, etc., and by the 5th→6th retry the delay is 5 seconds.
3. Cooldown window
   • If all 6 attempts fail, Azure Monitor stops retrying that alert invocation for 15 minutes. After that window, if the alert fires again, it will go through the same call-and-retry logic.
4. Global resilience of the Action Group service
   • The Action Group service itself is global: if one region is experiencing issues, calls are automatically routed to other regions.

Let me know if any further queries - feel free to reach out.

Reference links

• Troubleshoot “expected action didn’t trigger” (includes retry logic): https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-troubleshoot#the-expected-action-didnt-trigger
• Action Groups overview (global redundancy, action types): https://learn.microsoft.com/azure/azure-monitor/alerts/action-groups
• Service limits and testing Action Groups: https://learn.microsoft.com/azure/azure-monitor/alerts/test-action-group-errors