How we prevent CPU utilization alarms from repeatedly triggering during scheduled backup windows ?

Question

How we prevent CPU utilization alarms from repeatedly triggering during scheduled backup windows ?

Manish Rahul 65

I am currently experiencing repeated CPU utilization alarms whenever scheduled backup jobs are running. Since these backups are expected to consume additional system resources, the alerts generate unnecessary noise and make it difficult to identify genuine performance issues.

Would it be possible to implement anomaly detection thresholds or configure alarm suppression schedules during planned backup windows? This would help reduce false-positive alerts while still ensuring that unexpected CPU spikes outside the backup periods are detected and reported appropriately.

0 comments

2 answers

Your answer

Answer 1

Yes. A supported way to reduce alert noise during expected backup activity is to use an Azure Monitor alert processing rule to suppress notifications during a planned maintenance window.

For Azure Backup, the documented approach is:

Go to Resiliency > Monitoring + Reporting > Alerts.
Select Manage alerts > Manage alert processing rules.
Select + Create.
On Scope, choose the subscription or resource group the rule should cover.
If needed, add more granular filters so suppression applies only to a specific backup item.
On Rule settings, select Suppress notifications.
On Scheduling, define the backup window when alerts should be suppressed.
On Details, specify the subscription, resource group, and rule name, then complete Review + create.

Important behavior:

The suppression rule can exist alongside the main alert processing rule used for sending notifications.
By default, the suppression alert processing rule takes priority. If the same fired alert is affected by both rule types, the action groups for that alert are suppressed.
For one-off maintenance or backup windows, the suppression rule can be disabled after the window ends and re-enabled later when needed.

For high-frequency backup scenarios, the documentation also notes that some workloads such as SQL Server can generate failures as often as every 15 minutes, and suppression windows help avoid repeated notifications during expected events.

The provided documentation does not describe anomaly-detection thresholds for CPU alarms in this backup scenario. It does document these supported alerting options:

Built-in alerts using Azure Monitor for critical backup incidents.
Custom alerts using Azure Resource Graph or Log Analytics when custom logic is required.
Metric alerts using Azure Monitor metrics for status-style signals such as job success or failure.

If the goal is specifically to avoid repeated notifications during known backup periods, the directly documented solution is the scheduled suppression rule.

Answer 2

Hi,

It is a common monitoring design requirement and the recommended approach is usually to suppress or adjust alerting behavior during known maintenance activities such as backup windows rather than lowering CPU alert thresholds globally.

If your monitoring platform supports scheduled maintenance windows, alert suppression, or alert muting, configure the backup period as a recurring maintenance window. CPU metrics should continue to be collected and stored for historical analysis, but alarm generation and notifications can be suppressed only during the approved backup schedule. This prevents expected backup-related CPU utilization from generating incidents while preserving visibility into the actual resource consumption.

If maintenance windows are not available, the next best approach is dynamic or anomaly-based thresholding. In that model, the monitoring system learns the normal CPU baseline, including recurring backup activity, and only triggers an alert when utilization significantly deviates from the established pattern. This is generally more effective than static thresholds because it continues to detect abnormal spikes during backups, such as a runaway process pushing CPU far beyond the historical backup baseline.

From an operational perspective, I would recommend keeping the existing CPU collection and performance dashboards unchanged, implementing either scheduled alert suppression or dynamic thresholds, and adding a separate alert condition for sustained CPU saturation (for example, CPU > 95% for 15-30 minutes) if there is concern about backups masking genuine resource exhaustion events.

The exact implementation depends on the monitoring platform in use (SCOM, Azure Monitor, PRTG, SolarWinds, Zabbix, Nagios, Datadog, etc.), but the requirement itself is both feasible and aligned with monitoring best practices.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.