Creating a Custom Alert

Creating a Custom Alert

Summary

Custom Alerts let you build your own alert types in WISdom using a validated Custom Monitoring Query as the data source. You define which columns to evaluate, the condition that triggers the alert, how long it must persist, and how sensitive the threshold should be.

Once saved, WISdom treats Custom Alerts exactly like standard alerts — they appear in dashboards, can be assigned to Profiles and Rules, and follow the same alert lifecycle of open and close events.

Permissions required: Administrator or Power User — Admin Console → Monitoring
Prerequisite: At least one validated Custom Monitoring Query

Accessing Custom Alert Types

Custom Alerts are created and managed from the Alert Types screen.

1. Open the Admin Console.
2. Go to Monitoring.
3. Open Alert Types.

This list includes both standard (built-in) and custom alert types. Use the Alert Type filter to display only Custom Alerts. For each alert type, the list shows the Name, Description, Alert Type, number of Profiles assigned, number of Resources linked, and available actions.

Creating a Custom Alert

Step 1 — Start a new Custom Alert

1. From Admin Console → Monitoring → Alert Types, click the [+ Create Custom Alert Type] button in the upper right corner.
2. The Create Custom Alert Type flyout opens with multiple sections to be completed.

Step 2 — Define alert properties

In the Custom Alert Properties section at the top of the flyout, complete the following:

• Name (required) — Give the alert a clear, descriptive name that reflects what it monitors.
  Example: AlwaysOn Redo Queue Size — High
• Severity (required) — Set the default severity level for this alert: Informational, Warning, or Critical.
• Alert Categories (Optional) — Assign one or more predefined categories to help organize and filter the alert.
• Description (required) — Explain what this alert detects and why it matters.
  Example: Alerts when an AlwaysOn database redo queue size exceeds the configured threshold, indicating potential replication lag.

Step 3 — Define recommendations

In the Recommendations section, describe what someone should do when this alert fires.

This field is required and should be treated as a first-response playbook. Include what to check, how to confirm the issue, and where to find more information such as internal runbooks or relevant documentation.

Example:
Check network latency between the primary and replica. Review log send and redo rates in the Availability Group dashboard. Verify sufficient CPU and memory are available on the replica. Refer to the AlwaysOn runbook for escalation steps.

Step 4 — Configure the Custom Query mapping

The Custom configuration information will be displayed.

Select a validated query

From the Custom Query dropdown, select the validated query you want this alert to evaluate. Only queries with a Validated status appear here.

Once a query is selected, two additonal areas become available, a Tolerance tab and the query result set.

• The Tolerance tab is displayed next to the Custom tab
• The result set is loaded with the available result columns and displays sample rows from the most recent query execution to help you identify the correct columns to map.

Map the Value Column (required)

The Value Column is the numeric column from your query result that WISdom evaluates against the alert threshold.

• Value Column — Select the column containing the numeric metric to monitor.
  Examples: RedoQueueSizeKB, PercentUsed, FreeSpaceMB
• Value Name — Enter a friendly label for this value. This label appears in the alert message.
  Example: Redo Queue Size (KB)

Map the Object Column (optional, strongly recommended)

The Object Column identifies which specific object has crossed the threshold, such as a database, table, or drive. Without it, WISdom cannot distinguish between multiple objects in the same query result, and the alert cannot be consistently tracked across evaluations.

Why this matters: WISdom evaluates your query every minute and uses the Object Column as a stable key to track whether a condition persists over time. If no Object Column is defined, WISdom cannot reliably determine whether the same object is triggering the alert on subsequent runs. See the Designing Your Query: The Key/Value Pair Concept section in Custom Alert Query for guidance on choosing a good key.

• Object Column — Select the column that uniquely identifies the object being measured.
  Examples: DatabaseName, TableIdentityColumn, DriveLetter
• Object Name — Enter a friendly label for this object. This label appears in the alert message.
  Example: Database, Table, Drive

Set the Operator (required)

Choose the comparison operator that defines the alert condition. WISdom supports the following:

Example: Select > to alert when the measured value exceeds the threshold.

Step 5 — Configure tolerance settings

Ether click the Tolerance tab up top or select the Configure Tolerance button next to the Operator configuration. This changes to the Tolerance configuration area, where you will define the tolerance threshold values and how long the condition must persist before the alert fires.

Alerting Logic

The Alerting Logic field at the top of the tab displays a plain-language summary of your alert condition as it is currently configured, for example:

AlertingValue

This updates dynamically as you configure tolerance settings, giving you a clear confirmation of what the alert will do.

Add a Tolerance Setting

Click [+ Tolerance] to define your alert threshold.

• Tolerance Name — A label to identify this tolerance level.
  Example: Warning
• Alert Threshold — The numeric value that triggers the alert.
  Example: 80 (for 80% used)
• Duration (Minutes) — How many sequential minutes the condition must be true before the alert fires.
  Example: 5 minutes means the condition must remain true for 5 consecutive evaluations before WISdom opens the alert.

Tip: Use shorter durations for stable, slowly-changing metrics. Use longer durations for noisier metrics to reduce alert fatigue from brief spikes.

Adding Multiple Tolerance Levels

You can add more than one tolerance level to the same Custom Alert by clicking [+ Tolerance] again. Multiple tolerance levels allow you to configure the alert differently across Alert Profile levels — for example, sending a warning notification at one threshold and a critical notification at a higher threshold.

Each tolerance level appears in the Tolerance Settings list with its configured logic shown inline, for example:

identity: 1 sequential minute where Percent Used > 80

Use the edit (pencil) or delete (trash) icons on each row to modify or remove individual tolerance levels.

Step 6 — Save the alert

Click [Save] at the bottom of the flyout. WISdom validates that all required fields are complete and that the column mappings are consistent with the selected query's result set. If anything is missing or invalid, an error message will describe what needs to be corrected.

After saving, the alert appears in the Alert Types list with Alert Type = Custom.

Step 7 — Assign the alert to Profiles and Rules

A Custom Alert does not activate until it is added to an Alert Profile and assigned to resources. After saving:

1. Go to Admin Console → Monitoring → Profiles.
2. Open or create the Profile you want to assign the alert to.
3. Add your new Custom Alert, select the appropriate tolerance level, and configure notifications.

WISdom will then begin evaluating the alert on the instances linked to that Profile.

Using One Query for Multiple Alerts

A single validated query can be used as the data source for more than one Custom Alert. This is useful when a query returns multiple value columns that each warrant their own alerting condition or threshold.

Example: A query that monitors disk space might return both FreeSpaceMB and FreeSpacePercent for each drive. You can create one alert that fires when FreeSpacePercent < 15 and a second, more urgent alert when FreeSpacePercent < 5 — both using the same query, each configured with its own threshold, tolerance, and Profile assignment.

Editing a Custom Alert

1. Go to Admin Console → Monitoring → Alert Types.
2. Locate your Custom Alert using the filter or sort options. The Alert Type column identifies Custom versus WISdom alerts.
3. Click the row or select Edit from the action menu.

In Edit mode, you can change:

• Name, Description, Recommendations, and Severity
• Custom Query selection and column mappings
• Operator selection
• Tolerance settings
• Custom settings

Deleting a Custom Alert

1. From the Alert Types list, open the action menu for the alert.
2. Select Delete and confirm.

Before deleting, check the Profiles and Resources/Instances counts on the alert row to understand how many environments will be affected by removing it.

How Custom Alerts Are Evaluated

Once a Custom Alert is configured and assigned via Profiles, WISdom evaluates it automatically every minute:

1. Query execution — WISdom runs the Custom Monitoring Query against all configured Target Instances.
2. Result processing — For each row returned, WISdom reads the mapped Value Column, Object Column (if configured), and identifies the key/value pair for that object.
3. Condition evaluation — WISdom checks whether [Value] [Operator] [Threshold] is true for each object.
4. Tolerance tracking — WISdom tracks how long the condition has been continuously true for each object. When the condition persists for the configured duration, the alert opens.
5. Alert display — The alert appears in dashboards and alert screens with the auto-generated message identifying the object, recorded value, and threshold.
6. Alert closure — When the condition is no longer true for the required duration, WISdom closes the alert automatically following the standard alert lifecycle.

Understanding the Alert Message

WISdom automatically generates the alert message using your column mappings. You do not need to configure a message template — the message is built at runtime in the following format:

[Value Name] on [Object Value] is [Recorded Value]. Alert is on [Value Name] [Operator] [Alert Threshold].

Example:
If your Value Name is Percent Used, your Object Column returns HttpLog, and the threshold is 80:

Percent Used on HttpLog is 84.62. Alert is on Percent Used > 80.

This message appears wherever alerts are displayed in WISdom, giving your team an immediate understanding of what triggered the alert and at what level.

Best Practices

• Design stable keys — Make sure your Object Column returns a value that does not change between query runs. Avoid timestamps, row IDs, or any auto-incrementing values as keys. See the Designing Your Query: The Key/Value Pair Concept section in Custom Alert Query.
• Fully qualify user database objects — All Custom Monitoring Queries run in the context of the master database. Any query that references objects in a user database must use fully qualified names in the format DatabaseName.SchemaName.ObjectName, otherwise the query will fail at runtime.
• Use meaningful names — The Value Name and Object Name appear directly in alert messages. Clear, descriptive labels help your team understand what triggered the alert without having to look it up.
• Write thorough Recommendations — The Recommendations field is what your team reads when responding to an alert at 2am. Include what to check first, how to confirm the issue, and links to internal runbooks.
• Set realistic thresholds — Start conservative and adjust based on real behavior in your environment. Use tolerance durations to filter out transient spikes that do not require action.
• Test before deploying widely — Assign a new Custom Alert to a single non-critical resource first to verify threshold and tolerance behavior before rolling it out across all environments.
• Start focused — Begin with a small set of high-value custom alerts and expand gradually as you gain confidence in how they behave in your environment.

Related Topics

• Custom Monitoring Queries
• Alert Profiles
• Alert Rules
• Silencing Windows