Since alerts are supported in both production and development sandboxes, you can subscribe to them in any sandbox. When a sandbox is reset, all subscription alerts will also be reset, and when a sandbox is deleted, all subscription alerts will be deleted.
ÃÛ¶¹ÊÓƵ Experience Platform allows you to subscribe to event-based alerts regarding ÃÛ¶¹ÊÓƵ Experience Platform activities. Alerts reduce or eliminate the need to poll the Observability Insights API in order to check if a job has completed, if a certain milestone within a workflow has been reached, or if any errors have occurred.
When a certain set of conditions in your Platform operations is reached (such as a potential problem when the system breaches a threshold), Platform can deliver alert messages to any users in your organization who have subscribed to them. These messages can repeat over a pre-defined time interval until the alert has been resolved.
This document provides an overview of alerts in ÃÛ¶¹ÊÓƵ Experience Platform, including the structure of how alert rules are defined.
One-time alerts vs. repeating alerts
Platform alerts can be sent one time, or they can repeat over a pre-defined interval until they are resolved. The use cases of each of these options are intended to differ in the following ways:
One-time alert
Repeating alert
Does not necessarily indicate a problem.
Indicates a potentially undesirable state.
Does not repeat.
Can repeat if the anomalous condition persists.
Examples include:
Data ingestion has successfully completed.
A query execution has finished.
Data has been deleted.
Examples include:
Ingestion duration is exceeding the service-level agreement (SLA).
Daily ingestion did not happen over the past 24 hours.
The stream processor’s rate of error is above the configured threshold.
The total number of profiles is exceeding entitlement.
Anatomy of an alert
An alert can be broken down into the following components:
Component
Description
Metric
An Observability metric whose value triggers the alert, such as the number of failed batch ingestion events (timeseries.ingestion.dataset.batchfailed.count).
Condition
A condition related to the metric which triggers the alert if it resolves to true, such as a count metric exceeding a certain number. This condition may be associated with a pre-defined time window.
Window
(Optional) The condition for an alert may be constrained to a pre-defined time window. For example, an alert may trigger depending on the number of failed batches in the past five minutes.
Action
When an alert is triggered, an action is performed. Specifically, messages are sent to applicable recipients through a delivery channel, such as a pre-configured webhook or the Experience Platform UI.
Frequency
(Optional) An alert can be configured to repeat its action at a defined interval if its condition remains true or is otherwise unresolved.
Receiving and managing alerts
Alerts can be received and managed through two channels:
Alerts can be sent to a configured webhook to facilitate efficient automation of activity monitoring. In order to receive alerts via webhook, you must register your webhook for Platform alerts in ÃÛ¶¹ÊÓƵ Developer Console. See the guide on subscribing to ÃÛ¶¹ÊÓƵ I/O Event notifications for specific steps.
Platform UI ui
The Platform UI allows you to view received alerts and manage alert rules. The following video provides an introduction to these capabilities.
Transcript
In this video, I’m going to show you how to use the alerts feature in ÃÛ¶¹ÊÓƵ Experience Platform. Alerts allow you to subscribe to event-based messages related to various processes. Once your organization has implemented and started using Platform, you can use alerts to make sure things are running smoothly. For example, a data engineer can use alerts to monitor data ingestion processes, while a marketer could use them to make sure that their segment jobs are running smoothly. The alerts screen is under administration in the left navigation. On the browse tab, you can see all of the out-of-the-box alerts provided by ÃÛ¶¹ÊÓƵ. You can use the search box or a filters at the top to locate a particular alert or type of alert.
The alerts are provided out-of-the-box by various ÃÛ¶¹ÊÓƵ teams. Expect this list to grow in future releases. You can see the name of the alert, which service it’s related to, whether or not it’s enabled, and the last time the alert was triggered. Clicking on an alert opens the sidebar, which exposes additional details. Now, some alerts we call life cycle alerts. These are generated from an important event in the life cycle of a process, such as it completed or failed. Other alerts we refer to as metric alerts and these indicate things like a process that hasn’t completed in an expected timeframe. For example, this alert triggers when a segment job takes longer to process than a defined threshold. It’ll keep evaluating at the frequency specified and automatically change the alert status when the process completes.
Now, even though this alert evaluates every 30 seconds, it’s only going to notify you when the alert first triggers. An important distinction between the life cycle alerts and the metric alerts is that only the metric alerts will list a last triggered timestamp and display in the history tab. For each enabled alert, a user can decide whether or not they’d like to subscribe to it. Depending on your user permissions, you might also be able to enable or disable the alert for other users. Alerts will be emailed to the address associated with your ÃÛ¶¹ÊÓƵ ID. They’re also visible up here in the notifications area of the interface. Here’s an alert related to a source’s flow run failing. To find out more information, I can click on the notification and I’ll be taken directly to the details of the flow run where I can see that there is an error with my data. To see the alerts in the notifications area, you have to enable platform notifications, which you can do by clicking here in the gear icon, scrolling and using the toggle.
The ability to view and manage alerts is controlled in the ÃÛ¶¹ÊÓƵ AdminConsole where administrators can decide granular permissions related to platform features. For example, a user with a view alerts permission item can subscribe or unsubscribe to alerts, while someone with managed alerts can disable or enable an alert for other users.
Like with everything in platform, you can also interact with alerts via the API. You can subscribe to these events in the developer console and configure your own custom alert mechanisms using web hooks. I hope you enjoyed this overview of alerts. Stay alert. -
To work with alerts in the Platform UI, you must have the following access control permissions enabled through ÃÛ¶¹ÊÓƵ Admin Console:
Permission
Description
View Alerts
Allows you to view received alert messages.
View Alerts History*
Allows you to view a history of received alerts via the Alerts tab.
Manage Alerts*
Allows you to enable and disable alert rules via the Alerts tab.
Resolve Alerts*
Allows you to resolve triggered alerts via the Alerts tab.
*In order to access the Alerts tab, you must also be granted the View Alerts permission in combination with one of the other permissions.
With the View Alerts permission, can view received alerts by selecting the bell icon (
) in the top-right corner.
NOTE
Select an alert to navigate to a related dashboard for more detailed information on why the alert has been triggered.
In addition, the Alerts tab in the UI allows individual users to subscribe to specific alert types, and allows admins to enable or disable alert rules altogether. See the UI guide for more information on managing alerts.
Next steps
By reading this document, you have been introduced to Platform alerts and their role in the Platform ecosystem. Refer to the process documentation linked to throughout this overview to learn how to receive and manage alerts.
