Azure Monitor log alert firing repeatedly every 5 minutes for a single Automation runbook completion event

Hello Amol, it turns out nothing magical changed on the Azure side on 01-June-2026 – this is expected behavior when you use a Log Alert with a 5-minute lookback and static threshold of >=1 without any de-duplication logic. Here’s what’s happening and how you can fix it:

1. What’s happening under the covers
   • Your query (AzureDiagnostics | where …) runs every 5 minutes and looks back over the previous 5 minutes.
   • A single record that lands exactly at the start of the window (for example at 8:34 PM) will show up in multiple overlapping windows (8:29–8:34, 8:34–8:39, 8:39–8:44, etc.) until it “ages out.”
   • Because your alert is stateless (it simply fires whenever count ≥ 1) you get an email each evaluation period that still returns that same record.
2. How to stop the repeated firings Option A – Add a strict time filter so you only pick up new runs: ­ ­- Modify your query to explicitly filter for events in the current interval, for example:
   AzureDiagnostics | where ResourceProvider=="MICROSOFT.AUTOMATION" and Category=="JobLogs" and ResultType=="Completed" and RunbookName_s=="Restart-MyApp-Runbook" and TimeGenerated >= ago(5m) // <- only this interval
   ­ ­- Leave your frequency at 5 minutes and lookback at 5 minutes. Now once the job falls outside that window, it won’t trigger again. Option B – Group by JobId and only alert on the first occurrence: ­ ­- Summarize by JobId_g then count, and trigger when count == 1. ­ ­- That way you only fire once per JobId, regardless of how many windows it spans. Option C – Switch to a stateful Metric Alert on the “Total Jobs” metric: ­ ­- Azure Automation emits a TotalJobs metric you can filter by RunbookName and Status=Completed. ­ ­- Metric Alerts are stateful, so once they fire they won’t fire again until the condition clears and re-triggers. Option D – Use the alert’s advanced settings to reduce noise: ­ ­- Enable “Automatically resolve alerts” so only one alert is active at a time. ­ ­- Increase “Number of violations” or “Evaluation period” so you only fire after 2+ consecutive windows.
3. No known platform outage or backend change
   • We checked service health – no Log Analytics or Monitor outages on or after 01-June-2026.
   • This is simply how stateless log alerts work when your matching record overlaps multiple evaluation windows.

Give one of those options a try (adding the TimeGenerated filter is the quickest). That should restore you to a single email per run.

— Reference docs —

1. Troubleshoot duplicate log alert firings
2. Limit log alert query to time window
3. Use Metric Alert on Automation runbook metrics
4. De-duplication patterns in Kusto queries (summarize by JobId)

Hello Amol Garse •,

Greetings! Thanks for raising this question in Q&A forum.

The reason this is happening is actually not a platform bug or a recent Azure outage — it is the expected behavior of a stateless log alert with a 5-minute lookback window. When your runbook completes and writes a single log record, that same record keeps appearing in every overlapping 5-minute evaluation window until it "ages out." Since your alert simply fires whenever it finds count ≥ 1, it sends an email on every evaluation cycle that still sees that record — which is why you see emails at exactly 8:34, 8:39, 8:44 PM and so on.

Here is how you can fix this with a few easy options:

Option 1 (Quickest Fix) — Add a strict time filter to your query

Update your KQL query to only look at events from the very current interval by adding | where TimeGenerated >= ago(5m) like this:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.AUTOMATION"
    and Category == "JobLogs"
    and ResultType == "Completed"
    and RunbookName_s == "Restart-MyApp-Runbook"
    and TimeGenerated >= ago(5m)
| project TimeGenerated, RunbookName_s, ResultType, _ResourceId, JobId_g

This ensures once the job record is older than 5 minutes, it no longer matches the query and the alert stops firing.

Option 2 — De-duplicate by Job ID

Modify the query to group results by JobId_g and alert only on the first unique occurrence. Add a summarize line like this:

| summarize Count=count() by JobId_g
| where Count == 1

This way even if the same record appears in multiple windows, you only ever alert once per unique job.

Option 3 — Enable "Automatically Resolve Alerts" (Stateful Mode)

Go to your Alert Rule in the Azure Portal, click Edit, scroll to the advanced settings, and turn on "Automatically resolve alerts". This makes the alert stateful — once it fires, it won't fire again until the condition clears and then retriggers fresh.

Option 4 — Use the "Mute Actions" setting

In your Alert Rule, set "Mute actions for" to 60 minutes. This is a quick safeguard that suppresses repeat notifications even if the alert keeps evaluating as true.

Option 5 — Switch to a Metric Alert (Best Long-Term Option)

Azure Automation natively emits a TotalJobs metric that you can filter by RunbookName and Status = Completed. Metric alerts are stateful by design and will only fire once per event — no more duplicate emails. Go to Azure Monitor → Alerts → Create → Select signal type as Metric and choose Total Jobs from your Automation Account.

To directly answer your questions — there was no platform outage or backend change on 01-June-2026. This is simply how stateless log search alerts behave when the matching log record spans multiple overlapping evaluation windows. The fix is to either restrict the time window in your query (Option 1) or switch to stateful alert behavior (Option 3 or 5).

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.