Updated: 2025-10-20
Why create custom alerts?
Out-of-the-box, SAM comes with dozens of predefined alerts (for nodes down, SSL certificates expiring, application status changes, etc.).
But your environment likely has unique applications, thresholds, or stakeholders — custom alerts let you:
-
Monitor tailored conditions.
-
Notify the right people/groups.
-
Reduce noise by filtering out irrelevant alerts.
-
Automate actions when particular metrics are hit.
Step-by‐step: Creating a Custom Alert
Here’s a streamlined workflow.
-
Access Alert Management
-
In the SAM web console, go to Alerts & Activity → Alerts → Manage Alerts.
-
You can either duplicate an existing alert and edit it, or create a new one from scratch.
-
-
Define Alert Properties
-
If duplicating: select the alert, click Duplicate & Edit.
-
If new: click Add New Alert.
-
Enter a meaningful name, description, severity (Warning/Critical), what time-frame it’s evaluated etc.
-
Specify who can view/manage the alert (roles, teams) if needed.
-
-
Set Trigger Conditions
-
Select the object type you’re alerting on (node, application monitor, component, etc.).
-
Define one or more conditions. For example:
-
The monitored application status = Down.
-
The specific component metric > X threshold.
-
-
Use the “Add [+]” button if you need multiple trigger clauses.
-
You can target specific objects (e.g., certain applications, servers) or use groups.
-
-
Define Reset Conditions
-
When should the alert go away (reset)? For example, status returns to Up, metric falls beneath threshold.
-
Setting clear reset logic avoids “stuck” alerts and ensures you don’t get duplicates or lingering notifications.
-
-
Define Actions
-
What happens when the alert fires? Common actions: Send Email/Page, Log Event, Trigger Script, etc.
-
Configure the action details: recipient list (team alias or individuals), subject, body (use variables like
${Variable}for dynamic data). -
Optionally: define a different action for when it resets (e.g., “all clear” email).
-
-
Schedule & Scope
-
Set when the alert is active (24/7, business hours only, etc.), how often conditions are evaluated, and if there are any suppression windows.
-
Confirm the alert applies to only the relevant nodes/applications (scope) so you don’t flood yourself with irrelevant triggers.
-
-
Review & Submit
-
Review the summary of your configurations.
-
Submit and enable the alert. It will start monitoring based on your defined criteria.
-
Monitor the alert’s execution: you’ll see it in Active Alerts list when it fires.
-
Tips & Best Practices
-
Use meaningful naming: so when someone sees the alert, they know what it means and who should respond.
-
Avoid too many trivial alerts: custom alerts are powerful — too many minor ones = noise and alert fatigue.
-
Test your alert conditions: Use a non-production object or controlled threshold to ensure it triggers and resets as expected without unintended side-effects.
-
Use variables in messages: The
${variable}syntax allows you to include dynamic details (object name, value, etc). -
Document alert logic: If someone else inherits your environment, they’ll thank you for clear definitions of what triggers exist and why.
-
Review periodicity and suppression: If a system is undergoing heavy activity/maintenance, you may want to suppress alerts temporarily rather than disable them.
-
Use scopes wisely: Apply the alert only to relevant nodes/applications — this keeps results meaningful and your alert console clean.
Summary
Setting up custom alerts in SolarWinds SAM isn’t difficult — once you know the steps: define properties → trigger conditions → actions → review & enable. The real value lies in tailoring alerts to your environment and teams, reducing noise, and ensuring you’re notified only when something actionable occurs.
If you like, I can pull in some example templates (with queries/thresholds) or sample email body content you can copy and adapt. Would you like that?