Alerts & Rules

Breeze has a built-in alert system that monitors your devices and notifies the right people when something goes wrong. Alerts are triggered by rules you define, routed through notification channels you configure, and managed from the Alerts page in the dashboard.

Viewing Alerts

Open Alerts from the left sidebar to see all active alerts across your organization. The page has three main sections:

• Summary bar – counts of active alerts grouped by severity, with trend indicators showing whether alert volume is rising or falling.
• Filter bar – narrow the list by severity, status, device, or date range.
• Alert list – every alert with its severity badge, title, affected device, triggering rule, and timestamp.

Click any alert to open its detail view, which shows:

• Full alert message and context data
• The device that triggered it (with a link to the device page)
• The rule that fired (with a link to the rule editor)
• Status timeline (when it was triggered, acknowledged, resolved)
• Notification delivery history (which channels were notified and whether delivery succeeded)

Note

The main dashboard also shows the five most recent alerts in the Recent Alerts widget, auto-refreshing every 60 seconds.

Severity Levels

Every alert has a severity that controls how it appears in the dashboard and how notification routing handles it:

Severity	Use for	Color
Critical	Service-down conditions, security events, data loss risk	Red
High	Degraded performance, failed backups, disk nearly full	Orange
Medium	Threshold warnings, unusual patterns	Yellow
Low	Informational issues that may need attention	Blue
Info	Audit events, status changes, non-actionable notices	Gray

Alert Statuses

Alerts move through a lifecycle:

Status	Meaning
Active	The condition is still true and no one has responded yet
Acknowledged	A technician has seen the alert and is investigating
Resolved	The issue is fixed (manually or auto-resolved by the rule)
Suppressed	Silenced until a specified time, or indefinitely if suppressed Forever
Dismissed	Permanently closed and hidden from the list – and never raised again for the same condition. A terminal state

Responding to Alerts

Acknowledge an Alert

Acknowledging tells the team you are aware and working on it. From the alert list or detail page, click Acknowledge. The alert moves to “acknowledged” status and records who acknowledged it and when.

Resolve an Alert

Once the underlying issue is fixed, click Resolve. You can optionally add a resolution note describing what was done. Resolving an alert sets a cooldown period (configured on the rule) to prevent the same condition from immediately re-firing.

Suppress an Alert

If you need to silence a noisy alert during planned maintenance, click Suppress and choose how long it should stay silenced:

• 1 hour
• 8 hours
• 24 hours
• 7 days
• Forever – suppresses the alert indefinitely, with no automatic expiration

The alert moves to “suppressed” status and stops sending notifications. Timed suppressions are cleared automatically once the window elapses – the alert quietly returns to Active status on its own (so don’t be surprised if a suppressed alert reappears in the active list later without anyone touching it). Forever suppressions are the exception: they are never auto-expired and stay suppressed until you manually un-suppress the alert.

Note

Resolved alerts can’t be suppressed. Once an alert is marked Resolved, the Suppress control is no longer shown for it – suppression only makes sense for alerts that are still open.

Dismiss an Alert

Dismiss permanently closes an alert and takes it out of your way for good. Click Dismiss on any alert – from any status, including one that’s already Resolved – and it moves to the Dismissed state, disappears from the list, and cannot be brought back (dismissal is terminal). Dismissed alerts are hidden from the list by default; filter to the Dismissed status if you need to see them.

Dismiss differs from the other closing actions:

• Resolve marks the current issue fixed, but the rule can fire again the next time the condition recurs.
• Suppress Forever silences notifications while the condition is still live; the alert can return to Active if you un-suppress it.
• Dismiss is final – the alert is gone and won’t be raised again for the same condition.

Note

Dismiss is especially useful for warranty-expiry alerts. A dismissed warranty alert is honored by the evaluator that raises it, so it will never re-alert for that expiry – handy when you’ve deliberately decided not to renew. (If the device’s warranty is later renewed to a new expiry date, a fresh alert can still be raised for the new date.)

Bulk Actions

Select multiple alerts using the checkboxes, then choose Acknowledge Selected, Resolve Selected, Suppress Selected, or Dismiss Selected from the bulk action menu. Bulk suppressing prompts for the same duration options as a single alert, including Forever. You can act on up to 100 alerts at once.

Alert Correlation

When multiple related alerts fire at once (for example, a network outage causing many devices to go offline), Breeze automatically groups them using alert correlation. The correlation view shows:

• Root cause – the alert most likely to be the underlying problem, with a confidence score
• Related alerts – child alerts classified as causal, symptom, or duplicate
• Timeline – chronological view of when each related alert fired

Open the correlation view from the alert detail page when the “Related Alerts” badge appears, or go to Alerts → Correlations for a fleet-wide list of incidents with grouping and noise-reduction statistics. From an incident you can run on-demand Root Cause Analysis to gather evidence and propose a likely cause.

Alert Correlation and Root Cause Analysis are part of the AI Insights suite and may need to be enabled for your organization. See AI Insights for what they do, how to act on incidents, and how to turn them on.

Creating Alert Rules

Alert rules define what conditions to watch for and which devices to monitor.

1. Navigate to Alerts > Rules and click Create Rule (or open a Configuration Policy and go to the Alert Rules tab).

2. Give the rule a name and choose a severity level.

3. Add one or more conditions. Each condition specifies:

   • Type – metric threshold, status change, or custom condition
   • Metric – CPU, memory, disk, or network usage
   • Operator – greater than, less than, equals, etc.
   • Threshold value – the numeric value that triggers the alert
   • Duration – the sliding window over which samples are evaluated. The alert fires when the average of all samples within this window breaches the threshold (previously every individual sample had to breach). This change makes rules more tolerant of momentary spikes; if you had rules tuned for a single-sample breach, consider shortening the duration or lowering the threshold to preserve the same effective sensitivity.

4. Choose the target scope:

   • All Devices – applies to every device in the organization
   • Specific Sites – applies to all devices at selected sites
   • Specific Groups – applies to devices in selected device groups
   • Specific Devices – applies to individually selected devices

5. Select one or more notification channels to route the alert through.

6. Set the cooldown (1–1440 minutes) to prevent rapid re-firing after resolution.

7. Optionally enable auto-resolve so the alert resolves itself when the condition clears.

8. Click Save.

Testing a Rule

Before deploying a rule to production, you can test it against a specific device. From the rule list, click the Test button, select a target device, and Breeze will simulate condition evaluation and show you whether the rule would trigger.

Partner-wide Rules

A partner-scoped user with access to every organization can create an alert rule as partner-wide (“All organizations”) instead of scoping it to one org, so the same threshold or condition applies fleet-wide across every organization the partner manages. Choose the owner scope when creating the rule – it’s set once at creation and can’t be changed afterward. Partner-wide rules show an All orgs badge in the rule list.

Notification Channels

Notification channels are the delivery endpoints where alert notifications are sent. Each channel belongs to an organization.

Supported Channel Types

Type	Configuration Required
Email	Recipient email addresses
Slack	Incoming webhook URL
Microsoft Teams	Incoming webhook URL
Webhook	URL, HTTP method, headers, payload template
PagerDuty	Service/integration key
SMS	Phone numbers (requires Twilio configuration)
Pushover	Application token and user key (or inherit the partner default)

Setting Up a Channel

1. Go to Alerts > Channels and click Add Channel.

2. Enter a name (e.g., “Ops Team Slack”) and select the channel type.

3. Fill in the type-specific configuration (webhook URL, email addresses, etc.).

4. Click Save.

5. Click Test on the newly created channel to send a test notification and verify delivery.

A partner-scoped user with access to every organization can instead create the channel as All organizations (partner-wide) so one destination – a shared NOC Slack channel or PagerDuty service, for example – serves every org the partner manages. This choice is set at creation and can’t change later. Partner-wide channels show an All orgs badge and require partner-wide management access to edit, delete, or test-send. See Notifications for delivery details.

Notification Routing Rules

Routing rules let you control which channels receive which alerts, based on conditions like severity, alert type, device tags, or site.

1. On the Alerts > Channels page, expand the Routing Rules section.

2. Click Add Routing Rule.

3. Set a name and priority (lower number = higher priority; rules are evaluated in order).

4. Define conditions:

   • Severities – only route alerts of these severity levels
   • Condition types – only route alerts triggered by these condition types
   • Device tags – only route alerts from devices with these tags
   • Site IDs – only route alerts from devices at these sites

5. Select one or more notification channels to deliver to.

6. Choose an owner scope (partner users only) – This organization only or All organizations (partner-wide rule) – then enable or disable the rule and click Save.

Routing rules are evaluated from lowest priority number to highest, and org-owned and partner-wide rules compete in the same ordering – an org can define a higher-priority rule of its own to pre-empt a partner-wide rule. The first matching rule determines where the notification is sent. Partner-wide routing rules show an All orgs badge.

Escalation Policies

For critical alerts that need a guaranteed response, create escalation policies that notify progressively broader audiences if no one acknowledges within a given time.

1. Go to Alerts > Policies and click Create Policy.

2. Give the policy a name and define escalation steps. Each step specifies:

   • Which notification channels to contact
   • How long to wait before escalating to the next step

3. Attach the policy to alert rules by selecting it in the rule’s Escalation Policy field.

Like notification channels, escalation policies can be created partner-wide (ownerScope: "partner" via the API) so one escalation chain applies across every organization the partner manages. Creating, updating, or deleting a partner-wide escalation policy requires partner-wide management access.

---

Offline Duration for Configuration Policy Rules

Alert rules that detect when a device goes offline — configured via a Configuration Policy — include an Offline Duration field. This sets how long a device must be continuously unreachable before the alert fires.

Field	Description
Offline Duration	Minutes the device must be offline before triggering (1–1440, maximum 24 hours)

Setting a longer offline duration reduces noise from brief network hiccups or scheduled reboots. Setting a shorter duration catches devices that drop off unexpectedly. The field defaults to a sensible value for most environments; adjust it per-policy to match your SLA expectations for different device classes.

---

For infrastructure-level alerting (monitoring the Breeze platform itself with Prometheus and Alertmanager), see Infrastructure Alerts.