- Print
- DarkLight
- PDF
Alert Policies
- Print
- DarkLight
- PDF
Set up a Scout's alert policy to be notified based on the Scout's test results. You can create a different alert policy for each Scout.
You can create an alert policy at the time you create a Scout, or you can add one to an existing Scout by selecting Alert Policy in the Scout details window.
The alert policy you configure here can only send alerts based on a Scout's test result. If a Scout is not able to run a test (for example, if the Custom Hive running the Scout is down), you can receive an email alert. To learn more, visit Alerts for Stopped Scouts.
Create an Alert Policy for a Scout
Once you have opened the alert policy settings for a Scout, follow these steps to create an alert policy:
Set the conditions and behavior that trigger the alert.
- Set one or more test result Conditions that must be met for the alert to trigger. You can combine multiple conditions with AND or OR statements. The test result variables that you can use are different for each type of Scout.
- Set the number of subsequent tests that must meet the alert conditions to trigger the alert. For example, you might want to set this to a higher number so that you are not alerted every time there is a temporary issue that resolves itself.
- Set whether you want the alert policy to check that subsequent tests meet the conditions on the same hive or across all hives. This setting only makes a difference if your Scout is running from multiple Hives. If you select across all hives, then at least one hive per test run must meet the conditions that you specified, and it can be a different hive for each subsequent test. If you select same hive, then the same hive must meet the conditions that you specified.
Select how you want to be notified when the alert is triggered. You can use any of the following methods:
- Email. Add email addresses that will be sent an email when the alert is triggered, and when the alert is no longer triggered. The alert email is sent from
alerts@scoutbees.io
. - Webhook. Enter HTTP callbacks that are sent when the alert is triggered. Since webhooks use HTTP, they can be integrated into web services without adding new infrastructure. Enter an endpoint and authentication method for the webhook. You can also add custom headers and custom fields with variables that display additional data when the notification is received. See the table below for a list of webhook variables.
- Integration. You can set up an alert policy to notify you through third-party applications. If you have already set up integrations, then you can select them from the dropdown list. To add an integration, view the instructions for Microsoft Teams or ServiceNow.
- Do not send a notification. If you select this option, you will not receive any notification when the alert activates. This feature is useful only if you are using the Scoutbees API to view alert details. The API is the only way to view the alert details if you select this option.
- Email. Add email addresses that will be sent an email when the alert is triggered, and when the alert is no longer triggered. The alert email is sent from
Alert notifications are sent from a cloud server. If the location to which you are sending the alert notification is restricted by a firewall, then you must allow access to the cloud server.
To see the IP addresses you need to allow, visit IP Addresses used for Alerts.
Webhook Variables
Variable | Description |
---|---|
{scout.id} | The Scout's ID value |
{scout.resource} | The name of the resource being tested by the Scout (for EUC Scouts) |
{scout.name} | The Scout's name |
{scout.user} | The user name configured for authenticating the Scout (for EUC Scouts) |
{scout.address} | The address of the tested resource or gateway |
{test.ready_phase} | The duration for getting to the Session Ready state from the tested published resource (for EUC Scouts) |
{test.serv_nerame} | The server on which the Scout's session was opened (for EUC Scouts) |
{test.start_time} | The start time of the test |
{test.state_count} | How many times in a row the trigger has been triggered |
{test.status} | The status of the test (success/failure) |
{test.status_percents} | The success percentage of the test |
{test.body_size} | Response body size (HTTP Scouts) |
{test.cert_exp_date} | Certificate expiration date (HTTP Scouts) |
{test.connect_time} | Connect duration of the HTTP request (HTTP Scout) |
{test.dest} | Destination address of the HTTP request (for HTTP Scouts) |
{test.latency} | Total response time of the HTTP request (for HTTP Scouts) |
{test.namelookup_time} | DNS lookup duration of the HTTP request (for HTTP Scouts) |
{test.redirect_time} | Redirect/s duration of the HTTP request (for HTTP Scouts) |
{test.response_time} | Response duration of the HTTP request (for HTTP Scouts) |
{test.ssl_verified} | Whether the HTTP request connection is secure (HTTP Scouts) |
{test.tls_handshake_time} | TLS handshake duration of the HTTP request (for HTTP Scouts) |
{test.ttfb} | Time to First Byte of the HTTP request (HTTP Scouts) |
{test.status_code} | The status code of the HTTP request (for HTTP Scouts) |
{test.query_type} | The DNS query type {DNS Scouts} |
{test.result} | The responded records of the DNS query (for DNS Scouts) |
{test.runtime} | The total duration of the DNS query (for DNS Scouts) |
{test.server} | The DNS server being used for the query (for DNS Scouts) |
{test.packets_sent} | Number of packets sent during the test (for Ping Scouts) |
{test.packets_received} | Number of packets received during the test (for Ping Scouts) |
{test.jitter} | The average jitter time of all sent packets (for Ping Scouts) |
{test.avg_rtt} | The average latency of the test (for Traceroute and Ping Scouts) |
{test.min_rtt} | The lowest total latency of all packets sent during the test (for Traceroute and Ping Scouts) |
{test.max_rtt} | The highest total latency of all packets sent during the test (for Traceroute and Ping Scouts) |
{test.hops} | Number of hops the packets went through (for Traceroute Scouts) |