Creating Custom Alert Conditions

Server Scout's custom alert conditions allow you to monitor your servers precisely according to your requirements. Rather than relying on default thresholds, you can configure specific conditions that match your infrastructure's unique needs and alert preferences.

Accessing Notification Settings

To create custom alert conditions, navigate to your Server Scout dashboard and select the server you wish to monitor. Click on Settings in the server menu, then select Notifications from the sidebar. Here you'll find the option to Add Custom Condition.

Understanding the Add Condition Form

The add condition form contains several key fields that work together to define when and how alerts are triggered. Let's examine each component:

Metric Selection

The metric dropdown allows you to choose what system resource to monitor:

• CPU - Overall processor utilisation percentage
• Memory - RAM usage as a percentage of total available
• Disk - Storage utilisation for mounted filesystems
• Load - System load average (1, 5, or 15-minute intervals)
• Network - Incoming/outgoing bandwidth usage
• Processes - Number of running processes
• Uptime - Server availability status

Comparison Operators

Select the appropriate operator to define your threshold relationship:

• >= (greater than or equal to)
• > (greater than)
• <= (less than or equal to)
• < (less than)
• == (equals)

Threshold Value

Enter the numerical value that triggers the alert. This should correspond to your selected metric - for example, 90 for 90% disk usage or 5.0 for a load average of 5.

Severity Levels

Choose the appropriate severity level for your alert:

• Info - General notifications for informational purposes
• Warning - Issues requiring attention but not immediately critical
• Critical - Urgent problems requiring immediate action

Severity levels affect notification delivery methods and can be filtered in your alert management interface.

Sustain Period

The sustain period, measured in seconds, determines how long a condition must persist before triggering an alert. This prevents false alarms from temporary spikes or brief system fluctuations.

For example, setting a 300-second (5-minute) sustain period ensures that CPU usage must remain above your threshold for five consecutive minutes before generating an alert.

Cooldown Period

The cooldown period defines the minimum time (in seconds) between repeat notifications for the same condition. This prevents notification spam whilst ensuring you remain aware of ongoing issues.

A 3600-second (1-hour) cooldown means you'll receive at most one notification per hour for a persistent condition, even if it continues beyond the initial alert.

Practical Examples

High Disk Usage Alert

Create an alert for critically low disk space:

• Metric: Disk
• Operator: >=
• Threshold: 90
• Severity: Critical
• Sustain Period: 300 (5 minutes)
• Cooldown Period: 1800 (30 minutes)

This configuration alerts when disk usage reaches or exceeds 90% for five consecutive minutes, with notifications limited to once every 30 minutes.

Memory Warning

Set up a warning for elevated memory usage:

• Metric: Memory
• Operator: >=
• Threshold: 80
• Severity: Warning
• Sustain Period: 600 (10 minutes)
• Cooldown Period: 3600 (1 hour)

Load Average Monitoring

Monitor system load for performance issues:

• Metric: Load (15-minute average)
• Operator: >
• Threshold: 4.0
• Severity: Warning
• Sustain Period: 900 (15 minutes)
• Cooldown Period: 1800 (30 minutes)

Best Practices

When creating custom conditions, consider your server's normal operating patterns. Set thresholds that account for expected usage spikes whilst catching genuine problems. Use appropriate sustain periods to filter transient issues, and configure cooldown periods that balance awareness with notification fatigue.

Start with conservative thresholds and adjust based on your server's behaviour patterns. Monitor the effectiveness of your alerts and refine them as needed to maintain optimal server oversight.