How can we help?

How to Set Different Alert Severities for CPU Utilization Thresholds

Follow

Use separate alert definitions when you want different CPU utilization thresholds to generate different severities.

For example:

  • CPU utilization at or above 90% generates a Warning alert.
  • CPU utilization at or above 95% generates a Critical alert.

A single alert definition uses one severity. To assign different severities to different thresholds, create two alert definitions.

Before you start

Decide the following:

  • Which devices or sites should be monitored
  • The CPU thresholds for each severity
  • The notification channels for each severity
  • How long CPU utilization must remain elevated before the alert triggers
  • When each alert should clear

You may want Warning alerts to go to Email while Critical alerts go to Email and Zendesk or another escalation channel.

Create the CPU Warning alert

  1. Go to Manage Alerts.
  2. Open the Alerts v2 table.
  3. Click Create New Alert.
  4. Select CPU Utilization as the condition.
  5. Set the severity to Warning.
  6. Set the trigger condition to CPU utilization greater than or equal to 90%.
  7. Configure the scope to include the intended sites, devices, or device types.
  8. Add the notification channels for Warning alerts.
  9. Configure the clear condition.

For example:

  • Trigger: CPU utilization is greater than or equal to 90%.
  • Clear: CPU utilization is less than 85%.
  1. Add an evaluation period or alert delay if available.
  2. Save the alert.

Create the CPU Critical alert

  1. Create a second alert definition for CPU Utilization, or clone the CPU Warning alert.
  2. Set the severity to Critical.
  3. Set the trigger condition to CPU utilization greater than or equal to 95%.
  4. Use the same scope as the Warning alert unless the Critical alert should apply to different devices or sites.
  5. Add the notification channels for Critical alerts.
  6. Configure the clear condition.

For example:

  • Trigger: CPU utilization is greater than or equal to 95%.
  • Clear: CPU utilization is less than 90%.
  1. Add an evaluation period or alert delay if available.
  2. Save the alert.

Using separate clear thresholds

Separate clear thresholds can help prevent alert flapping.

Example:

  • Warning triggers at 90% and clears below 85%.
  • Critical triggers at 95% and clears below 90%.

With this configuration, a device may have both alerts active while CPU utilization remains high. The Critical alert clears when CPU utilization drops below 90%, while the Warning alert remains active until CPU utilization drops below 85%.

  • Choose clear thresholds that reflect when the underlying issue has recovered, rather than simply using the trigger threshold.
  • Choose the alert scope

The two alert definitions can use the same scope or different scopes.

Use the same scope when:

  • The same devices should receive both Warning and Critical alerts.
  • You want consistent CPU monitoring across a site or device group.

Use different scopes when:

  • Core infrastructure requires stricter monitoring than endpoints.
  • Servers and network devices need different CPU thresholds.
  • Only specific device types should generate Critical alerts.
  • Different sites have different performance requirements.

Review the notification channels

Confirm that each alert is associated with the correct notification channels.

For example:

  • CPU Warning: Email notification channel
  • CPU Critical: Email and Zendesk notification channels

Review the notification channels at both the alert and site level if alerts are configured through parent or organization inheritance.

A child site or alert definition with customized notification channels may not receive later changes made at the parent level.

Reduce unnecessary alert noise

To reduce notifications caused by brief CPU spikes:

  • Add an evaluation period so CPU must remain above the threshold before triggering.
  • Use an alert delay when available.
  • Avoid setting the Warning and Critical thresholds too close together.
  • Use maintenance windows during planned upgrades, backups, or other high-CPU activities.
  • Use different scopes for infrastructure devices, servers, and endpoints when their normal CPU behavior differs.

Test the alert configuration

Use Auvik’s Send Test Alert function to verify notification-channel delivery when possible.

To validate the alert conditions themselves, use a non-production test device or an approved maintenance window.

If you temporarily lower a threshold:

  1. Record the original threshold.
  2. Change the threshold only for the test alert or test device.
  3. Confirm that the Warning and Critical notifications are delivered through the expected channels.
  4. Restore the original threshold immediately after testing.
  5. Confirm that the alert definitions are enabled and scoped correctly.

Review alert history

After testing, review Alert History to confirm:

  • The Warning and Critical alerts triggered independently.
  • Each alert used the intended severity.
  • The correct notification channels were used.
  • The clear conditions worked as expected.
  • No duplicate or unexpected alerts were generated.

Related articles

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Auvik System Status

Check system status