Default Alert Conditions Explained

Understanding Server Scout's Pre-Configured Alerts

When you add a new server to Server Scout, the system automatically creates a comprehensive set of alert conditions to monitor critical system resources. These default conditions provide immediate protection for your infrastructure without requiring manual configuration, though they're designed to be customised for your specific environment.

Default Alert Conditions

Server Scout establishes four core monitoring conditions for every new server:

CPU Usage Alerts

• Warning threshold: 80% CPU utilisation
• Critical threshold: 90% CPU utilisation
• Sustain period: 2 minutes
• Cooldown period: 5 minutes

Memory Usage Alerts

• Warning threshold: 80% memory utilisation
• Critical threshold: 90% memory utilisation
• Sustain period: 2 minutes
• Cooldown period: 5 minutes

Disk Usage Alerts

• Warning threshold: 80% disk space used
• Critical threshold: 90% disk space used
• Sustain period: 5 minutes
• Cooldown period: 10 minutes

Server Offline Detection

• Trigger condition: No data received for 60+ seconds
• Sustain period: Immediate
• Cooldown period: 2 minutes

How Sustain and Cooldown Periods Work

The sustain period prevents false alarms by requiring a condition to persist for the specified duration before triggering an alert. For example, CPU usage must remain above 80% for 2 full minutes before a warning alert fires.

The cooldown period prevents alert spam by enforcing a minimum time between repeated alerts for the same condition. Once a CPU warning alert fires, another won't be sent for at least 5 minutes, even if the condition persists.

Global Application

These default conditions apply universally to all servers in your Server Scout organisation. When you add your first server or your fiftieth, each receives the same baseline monitoring configuration. This ensures consistent protection across your infrastructure whilst providing a solid foundation for customisation.

Modifying Default Conditions

To adjust the default alert conditions that apply to all servers:

1. Navigate to Settings > Notifications in your Server Scout dashboard
2. Locate the Default Alert Conditions section
3. Modify thresholds, sustain periods, or cooldown periods as needed
4. Click Save Changes

Changes to default conditions only affect newly added servers. Existing servers retain their current alert configurations unless specifically updated.

Creating Per-Server Overrides

Some servers require different monitoring thresholds due to their specific roles or usage patterns. For example, a continuous integration build server might regularly consume 95% CPU during normal operation, making the default 90% critical threshold inappropriate.

To create server-specific alert conditions:

1. Go to Servers and select the server requiring custom thresholds
2. Click the Alert Conditions tab
3. Toggle Use Custom Conditions to enable per-server overrides
4. Adjust thresholds and timing parameters as required
5. Save your changes

Common scenarios for custom conditions include:

• Database servers: Often require lower memory thresholds (60-70%) due to buffer pool usage patterns
• Web servers: May need tighter disk space monitoring (70-80%) to prevent log files filling partitions
• Development servers: Often require higher CPU thresholds (95%+) to accommodate intensive build processes

Tuning for Your Environment

Whilst Server Scout's defaults provide sensible starting points based on industry best practices, they should be adjusted to match your specific infrastructure requirements. Consider these factors when tuning alert conditions:

• Server roles and typical workloads
• Business hours vs. maintenance windows
• Historical performance patterns
• Criticality of individual systems

Monitor your alert frequency during the first few weeks after deployment. If you're receiving too many alerts, consider raising thresholds or extending sustain periods. Conversely, if critical issues go unnoticed, lower thresholds or reduce sustain periods accordingly.

The goal is achieving a balance where genuine issues trigger timely alerts without overwhelming your team with false positives. Regular review and adjustment of these conditions ensures your monitoring remains effective as your infrastructure evolves.