Alerts¶

Alerts proactively notify relevant personnel when exceptions occur during data loading or data processing. Monitoring answers “what happened”; alerts ensure that exceptions reach the right people promptly when human intervention is required.

Three components of an alert¶

Object	Purpose	When to use it
Alert rule	Defines trigger conditions, alert severity, and notification frequency	Establish monitoring conditions for critical tasks or quality risks
Notification recipient	Defines who receives messages and through which channel	Prepare recipients before creating rules
Alert record	Records exceptions that have been triggered	After receiving a notification, review the rule, time, and exception type

Configure and use alerts in the recommended order: Notification Recipients → Alert Rules → Alert Records. This ensures that a triggered rule can send messages to the correct individual, on-call group, or collaboration group.

Create and manage alert rules¶

An alert rule consists of an alert template, threshold, severity, notification recipient, notification interval, and enabled status. Threshold fields differ by template. Templates such as “a failure exists” do not require a threshold.

Field	Description
Alert template	Select the data-loading or data-processing exception to monitor
Threshold	Set a trigger boundary for metrics such as file count, duration, success rate, or backlog
Alert severity	Select Notice, Important, or Critical so recipients can respond by priority
Notification recipient	Select one or more enabled notification recipients
Notification interval	Controls the frequency of repeated notifications for the same exception; it can also be set to notify only once
Enabled status	Determines whether the rule starts monitoring immediately after creation

First create a recipient under Notification Recipients.
Open Alert Rules and click Create Alert Rule.
Select an alert template and enter the threshold as prompted.
Select the alert severity, notification recipients, notification interval, and enabled status.
Save the rule and confirm in the rule list that its status is Monitoring.

The rule list supports searching by alert expression, pagination, and maintenance. You can edit a rule, temporarily disable it, permanently disable it, re-enable it, or delete it when it is no longer needed.

Temporary disabling is suitable for reducing noise during a maintenance window or known exception. Permanent disabling is suitable for rules that are not currently in use. Before re-enabling a rule, confirm that its notification recipients and thresholds still match current business objectives.

Available alert templates¶

Alert templates are organized into data loading and data processing categories. When creating a rule, refer to the templates and fields currently displayed in the UI.

Type	Alert expression
Data loading	File count in a single load task exceeds the threshold
Data loading	Average file load time in a single load task is greater than the threshold
Data loading	Load success rate in a single load task is less than the threshold
Data loading	A file with the same name is loaded
Data loading	A data load failure exists in a single load task
Data processing	Number of files simultaneously waiting for processing in the workspace is greater than the threshold
Data processing	Number of files simultaneously waiting for processing in a single job is greater than the threshold
Data processing	Average file processing duration in a single job is greater than the threshold
Data processing	A file processing failure exists in a single job
Data processing	File processing success rate in a single job is less than the threshold
Data processing	Number of files processed by a single job exceeds the threshold
Data processing	Single-file processing duration is greater than the threshold
Data processing	Number of segments in a single file is greater than the threshold

When setting thresholds, first use historical duration, backlog, and success rate during normal operation as a baseline, then allow room for normal fluctuations. Overly strict thresholds create noise, while overly loose thresholds delay the detection of genuine problems.

Manage notification recipients¶

Notification recipients determine the channels and recipients to which alert messages are delivered. Current options include email, SMS, phone call, and WeCom.

Type	Required information	Common use
Email	Email address	Send to an individual’s mailbox or a team mailing list
SMS	Mobile phone number	Send high-priority reminders
Phone call	Mobile phone number	Handle critical events that require a strong reminder
WeCom	WeCom Webhook Key	Send to an on-call group or collaboration group

On the Notification Recipients page, click Create Notification Recipient.
Enter a name and select a notification type.
Enter the contact information required by the channel and add notes if needed.
Save and confirm that the notification recipient is enabled.

You can search, edit, enable, disable, and delete notification recipients. Before deleting or disabling one, check whether any alert rules still reference it, or an exception may trigger without anyone receiving a notification.

Create notification recipients based on team responsibility or on-call roles, such as “Data Platform On-Call Group” or “Workflow Maintenance Mailing List.” When personnel change, you only need to maintain the notification recipient instead of modifying every alert rule.

View and handle alert records¶

Whenever a rule’s trigger condition is met, the system generates an alert record. The alert record list is ordered by alert time and supports searching by rule ID or alert expression and viewing results by page.

Field	Description
Alert time	Time when the exception was triggered
Alert rule ID	Identifier of the rule that generated the record
Alert expression	Exception condition that was actually matched
Alert severity	Notice, Important, or Critical
Status	Read or unread

After receiving a notification, follow these steps:

Confirm the trigger time, rule, and expression in the alert record.
For data-processing exceptions, open Jobs and review the failed node, execution state, and error information.
For SQL performance issues or query failures, open SQL History and review the query details and execution plan.
For API submission, parameter, or permission issues, open Operation Logs and review the current user’s request record.
After handling the issue, adjust the rule threshold, notification interval, or notification recipients as appropriate.

Read means that someone has viewed the record; it does not mean the exception has recovered. Alert records preserve the fact that a trigger occurred. The specific response, remediation, and review should be incorporated into your team’s own on-call or issue-management process.

Boundaries with other alert systems¶

This page describes data-loading and data-processing alerts in an AI Studio workspace. Genesis model-service notifications, billing alerts, MatrixOne instance alerts, and database operations alerts belong to their respective platform domains and do not share the rules, notification recipients, or records described here.