Notification Policies in Proberix

Notification Policies in Proberix define the conditions under which notifications are sent and the channels through which they are delivered. These policies allow users to customize alert criteria and notification methods, ensuring that notifications are sent only when necessary and to the appropriate recipients.

For example, brief, isolated issues that do not impact overall service might not trigger any notifications, while more serious and prolonged problems that affect multiple locations would result in an alert.

Failure-Based Location Down Criteria

A Notification Policy begins with setting thresholds for problematic events, determining what qualifies as a "down" status for your monitored endpoints. A problematic event can be a simple connection timeout, an availability error, a response assertion mismatch, or performance degradation. However, a single event alone will not trigger a notification to prevent unnecessary alerts caused by temporary fluctuations, network hiccups, or isolated failures. Instead, Proberix ensures that notifications are only sent when these events cross predefined thresholds, escalating them into persistent incidents or widespread issues that require attention.

For example, when monitoring an API endpoint from multiple locations, you can set a Consecutive Failure Threshold. This threshold specifies how many consecutive failed attempts from a single location are required before the endpoint is considered "down" from that location. If the threshold is set to 2, the endpoint will only be considered down if the probe fails two times in a row at a specific location. This helps to ensure that only consistent and significant issues trigger a down status.

Performance-Based Location Down Criteria

In addition to failure-based thresholds, a location can also be marked as "down" based on performance degradation. Users can enable this option by selecting the Enable Performance Threshold checkbox. When enabled, they must specify a value for the threshold in milliseconds. The system continuously calculates a 10-minute rolling average response time for every probe result. If this rolling average exceeds the specified threshold, the location is considered "down." This setting helps identify performance-related issues beyond simple failures, ensuring alerts are triggered for both outages and severe slowdowns.

Multi-Location Consensus Threshold

This threshold determines how many locations must report the endpoint as down before a notification is triggered.

For example, if the location threshold is set to 2, Proberix will only send a notification if at least two locations detect that the endpoint is down according to the defined criteria.

Notification Channels and Policy Customization

Notification Policies also allow you to select the channels through which alerts are sent, such as Email, SMS, or Webhooks. You can configure these channels to ensure that alerts reach the right people promptly.

Example: Multi-Channel Notifications

For instance, you might set up a Notification Policy that sends an email to your operations team when two locations report an endpoint as down. At the same time, the policy could also send an SMS to an on-call engineer for immediate attention.

These policies can be easily updated. If you need to change the notification recipients or add another channel, you can adjust the policy settings, and the changes will apply to all associated probes.

Send Change Detection Notifications

You can choose to enable notifications specifically for changes detected by the probe. This setting allows you to receive alerts as soon as Proberix identifies a difference between the current content and the baseline.

Silence Period Following a Change Notification

To prevent an overload of notifications, you can set a Silence Period after each change notification. This is a quiet interval during which no further change notifications will be sent, even if additional changes are detected. This helps to reduce noise and allows you to focus on addressing the initial alert before receiving more.

• Silence Period Options:
  • No Silence Period: Enables immediate notifications for every detected change from every location, with no delay between alerts.
  • 1 Hour
  • 2 Hours
  • 3 Hours
  • 6 Hours
  • 8 Hours
  • 12 Hours

By choosing the appropriate silence period, you can balance between being promptly informed of issues and avoiding unnecessary notification noise.