Alert Webhook

The Alert Webhook sends WISdom alert data to an endpoint you control, in a structured JSON format. Unlike the ticketing system integrations, which build message text from templates, the Alert Webhook delivers WISdom-native data fields that your system can parse and route however you need.

Setup has three parts: connect the webhook, create a Notification Channel that points to it, then assign that channel to alert severities on a Profile. WISdom then posts to your endpoint each time a matching alert opens, escalates, de-escalates, or closes.

Before you begin

• You must have the Admin role. The Integration page is not available to other roles.
• Your endpoint must be reachable over HTTPS from the public internet and must accept POST requests with a JSON body.
• You need an API token that your endpoint will accept as a bearer token.
• If your endpoint sits behind a firewall, allow inbound traffic from the WISdom source IP ranges listed below.

Source IP ranges

WISdom sends webhook requests from three ranges, distributed across US East 2 and US Central for volume and redundancy. Allow all three.

Range
20.85.14.224/29
20.236.234.64/29
20.122.252.88/32

Key concepts

Alert scope: Every webhook message identifies whether the alert is a System alert or a Server alert. The scope field carries this value, and it determines which fields are present in the payload.

Scope	Triggered by	Identifies the source using
Server	An issue on a monitored server	serverName, platformName
System	An issue collecting data	collectorName, collectorMachineName

Event type: Each message identifies where the alert is in its lifecycle. All messages for the same alert share the same alertId, so your system can correlate them.

eventType	Sent when	Delivered by
AlertOpen	The alert first triggers.	Notify on Open Events
AlertEscalate	The alert moves up to a higher configured level.	Notify on Open Events
AlertDeescalate	The alert moves down to a lower configured level.	Notify on Closed Events
AlertClose	The alert condition clears.	Notify on Closed Events

Alert levels: Alert types that support multiple severity levels generate a message at each transition. An alert configured with three levels can produce an AlertOpen, two AlertEscalate events, two AlertDeescalate events, and an AlertClose, all carrying the same alertId.

Notification Channel: A connected webhook does not deliver anything on its own. You create a Notification Channel that points to it, then assign that channel to alert severities on a Profile.

Step 1, Connect the webhook

1. Go to Admin Console › Integration.
2. Under Available Apps, select the WISdom Webhook card. It is labeled Alert Webhook.
3. In the Connect Alert Webhook dialog, complete the fields:

Field	Required	Description
Alert Webhook	Read-only	Displays WISdom Webhook.
Name	Yes	A unique name for this webhook. This name identifies the webhook on the Integration page and in the Notification Channels list.
Endpoint	Yes	The full URL to call, including protocol. For example, https://example.com/my-webhook.
Token	Yes	The API token WISdom passes to your endpoint.

1. Select Test connection. WISdom posts a complete sample payload to your endpoint. The message field contains wording that clearly identifies it as a test message.
2. Select Save.

The webhook moves from Available Apps to Connected Apps, and the card displays the name you assigned.

More than one webhook may be configured. Each configuration must have a unique name.

Step 2, assign the webhook to a notification channel

Connecting the webhook makes it selectable when you build a Notification Channel. No alerts are sent until you create and assign that channel.

1. Go to Admin Console › Monitoring › Notification Channels.
2. Expand the Ticketing System section and add a channel.
3. Enter a Name for the channel. This is the name that appears in the Profile channel picker.
4. Open the Ticketing System drop-down and select your webhook by the name you gave it in Step 1.
5. Save the channel.

The channel name and the webhook name are independent. Using the same value for both makes the relationship easier to trace later.

Step 3, assign the channel to a Profile

1. Go to Admin Console › Monitoring › Profiles and edit the Profile you want to use.
2. Either select the Notifications radio button, or step through to Notifications.
3. For each severity you want delivered, open the Channels drop-down under Notify on Open Events, Notify on Closed Events, or both. Select your channel and select Apply.
4. Select Save.

Open and closed events are assigned separately

Notify on Open Events delivers AlertOpen and AlertEscalate. Notify on Closed Events delivers AlertDeescalate and AlertClose. Assign the channel to both columns if you want your endpoint to receive the full alert lifecycle.

Managing a connected webhook

Hover over the webhook card under Connected Apps to reveal the edit and delete icons.

• Edit opens the Edit Connected Alert Webhook dialog, where you can change the name, endpoint, or token. The stored token is masked. Test connection is available here as well.
• Delete removes the webhook. Any Notification Channel pointing to it will stop delivering, and any Profile severity using that channel will no longer notify. Update those references first.

Request format

WISdom sends an HTTP POST with a JSON body and the following headers:

Header	Value
Content-Type	application/json
Authorization	Bearer

If you set the token to my-token, WISdom sends Authorization: Bearer my-token.

Delivery and retries

If your endpoint does not respond successfully, WISdom retries the request twice using exponential backoff. After the final attempt, the message is dropped.

Delivery failures are not currently surfaced in WISdom

There is no customer-facing log of failed webhook deliveries. Monitor receipt on your own endpoint to confirm that alerts are arriving.

Payload reference

Fields common to all Alerts

Field	Type	Description
alertId	string	Uniquely identifies the alert. Every message for the same alert carries the same value.
eventType	string	AlertOpen, AlertEscalate, AlertDeescalate, or AlertClose. See Key Concepts above.
scope	string	System or Server.
accountName	string	The name of the account the alert belongs to.
accountDisplayName	string	The friendly name configured in Admin Console › Account › Display Name.
openDateTime	string	ISO-8601 UTC time. Populated on AlertOpen and AlertEscalate.
closeDateTime	string	ISO-8601 UTC time. Populated on AlertDeescalate and AlertClose.
alertType	string	The type of alert.
message	string	A human-readable description of the alert. Format varies by alert type. See Alert Message Format.
targetObjectName	string	The object the alert refers to. See the note below.
alertDetailsUrl	string	A direct link to the Alert Details view for this alert in WISdom.

A de-escalation is not a close

AlertDeescalate populates closeDateTime, but the alert is still open. The alert is not closed until AlertClose is sent, and that timestamp is what appears as the close date in Health › Alerts › Details. Do not treat a populated closeDateTime as a resolved alert.

Not every alert has a target object

On Server alerts, targetObjectName is always present. It names whichever object the alert refers to, such as a drive, stored procedure, SQL Agent job, database, instance, host, or process. Additional object types may be exposed as alerting expands, so do not validate the value against a fixed list.

targetObjectName is not available on System alerts. Where a System alert relates to a specific target, that detail is carried in the message field instead. On Collection errors, message includes the affected target and its host, the error type, the first and last occurrence, and possible solutions. The same detail appears in the Alert Details flyout that alertDetailsUrl opens, where the target is shown as the Resource.

Opening the alertDetailsUrl will open WISdom in your default browser. It will attempt to open the Health › Alerts › Details page for that specific alert, with the Alert Details flyout opened. For MSP accounts, the link also resolves to the correct client account. Use the value exactly as provided rather than constructing the URL yourself, as the link format is subject to change.

Following the alert link requires a WISdom account

Recipients need a WISdom account to open the link, and will be prompted to sign in if they are not already authenticated.

Server Alert fields

Field	Type	Description
serverName	string	The server that triggered the alert.
platformName	string	The platform of the server that triggered the alert.
failureCount	number	The number of times the rule that triggered the alert failed.
successCount	number	The number of times the rule passed. Non-zero only on AlertClose.

System Alert fields

Field	Type	Description
collectorName	string	The collector that triggered the alert.
collectorMachineName	string	The machine where the collector is running.

Sample payloads

Server Alert

{
    "alertId": "WBg6NSK8XPBCQHHovmB7ow==",
    "eventType": "AlertOpen",
    "scope": "Server",
    "accountName": "ABC Industries",
    "accountDisplayName": "ABC",
    "openDateTime": "2025-01-01T00:00:00Z",
    "closeDateTime": null,
    "alertType": "Low Disk Space",
    "message": "This is a sample server alert",
    "serverName": "Server1",
    "targetObjectName": "C:",
    "platformName": "Microsoft SQL Server",
    "failureCount": 1,
    "successCount": 0,
    "alertDetailsUrl": "https://app.fortifiedwisdom.com/health/alerts_details/{alert-specific-link}"
}

System Alert

{
    "alertId": "WBg6NSK8XPBCQHHovmB7ow==",
    "eventType": "AlertOpen",
    "scope": "System",
    "accountName": "ABC Industries",
    "accountDisplayName": "ABC",
    "openDateTime": "2025-01-01T00:00:00Z",
    "closeDateTime": null,
    "alertType": "Sample system alert type",
    "message": "This is a sample system alert",
    "collectorMachineName": "Machine1",
    "collectorName": "Collector1",
    "alertDetailsUrl": "https://app.fortifiedwisdom.com/health/alerts_details/{alert-specific-link}"
}

Alert message format

The message field is written for a human reader, and its shape varies by alert type. There is no single structure that applies to every alert, so the examples below are representative rather than exhaustive.

Most alerts return a single line stating the observed value and the tolerance that tripped the alert:

Processor\% Processor Time (_Total) is 97.08334. Alerting is on value >= 95

Disk Free space on T: is 10MB. Alert is on Disk Free space <= 20000MB, Disk Free % on T: is 0.03909151%. Alert is on Disk Free % <= 10%

Some carry no measurement at all:

The Availability Group has failed over

A smaller number of alerts return several lines, most of them in Label: value form. In the Alert Details flyout, this content sits under the Alert Message heading, which is the interface equivalent of the message field and is not part of the value itself. A Collection errors alert is one example:

ServerName: <InstanceName> (SQL Server)
Host(s): <HostName>
Database:
Error Type: The Collector is unable to connect to SQL Server - [Timeout attempting to open the connection. The time period elapsed prior to attempting to open the connection has been exceeded. This may have occurred because of too many simultaneous non-pooled connection attempts.]
First Occurrence: 2026-08-02 21:16:05
Last Occurrence: 2026-08-02 21:46:05
Possible Solutions: Please make sure the server is up and running, and the machine running the Collector can connect to it using the provided name

In this message, ServerName identifies the target the error occurred on, followed by an object type label in parentheses. Host(s) names the host the target runs on, which may be the same value as ServerName. A label may appear with no value, as Database: does when the error is not specific to a database.

For Collection errors, the message is otherwise fixed. Only the names and the occurrence timestamps change. WISdom does not always pass through the error text it collected. Messages are deliberately generalized so that one message can cover several underlying errors, which means the bracketed detail describes the class of problem rather than quoting the collector verbatim.

A SQL Server Agent Job Failed alert is another, with a different set of labels:

Date: 2026-08-03 07:43:33
Step: <JobStepName> (<StepNumber>)
Message: Executed as user: <Domain>\<AccountName>. Could not find stored procedure '<DatabaseName>.dbo.<ProcedureName>'. [SQLSTATE 42000] (Error 2812). The step failed.

On the Step line, <JobStepName> is the job step name as defined in SQL Server and seen in SQL Server Management Studio, and <StepNumber> is the step number, which WISdom appends. A step that executes a stored procedure might read EXEC <ProcedureName> (3). Step names read differently in every environment, so do not expect a consistent pattern within them.

The name of the failed job is not in the message. It is carried in targetObjectName, and appears as the Object in the Alert Details flyout.

Treat the message field as display text

Because the format varies by alert type and can change between releases, do not build logic that depends on parsing message. Use the typed fields for routing and automation: alertType to identify the condition, targetObjectName and serverName to identify what it applies to, and eventType to track lifecycle. Pass message through to whoever reads the alert.

Where you do need a value out of a multi-line message, the lines are separated by \n inside the single JSON string. Split on the newline, then on the first colon of each line. Splitting on the first colon matters, because a value can contain further colons of its own. In the Agent Job example above, the value of Message opens with Executed as user:.

Troubleshooting

Symptom	Likely cause
Test connection fails	The endpoint is unreachable, is rejecting the bearer token, or WISdom source IPs are not allowed through your firewall.
Test connection succeeds, but no alerts arrive	No Notification Channel points to the webhook, the channel is not assigned to a severity on a Profile, or no alert at that severity has triggered.
Open and escalation events arrive, but de-escalations and closes do not	The channel is assigned under Notify on Open Events only. Add it to Notify on Closed Events.
Several messages arrive for one alert	The alert type has multiple levels configured. Escalations and de-escalations arrive as separate AlertEscalate and AlertDeescalate messages sharing the same alertId.

Related topics

• Integration
• Notification Channels
• Profiles
• Alert Rules
• Account