Monitoring and Alerts¶
Monitoring helps you investigate execution records, query details, and API operations after a problem occurs. Alerts proactively notify you when an exception occurs. Together, they provide a complete feedback loop from detecting an exception and locating its cause to adjusting rules.
Monitoring entry points¶
Page |
Primary question answered |
Current scope |
|---|---|---|
Did a SQL statement succeed, how long did it take, and what was its execution plan? |
The query history entry point is controlled by a product feature flag |
|
What is the status of a workflow execution, and which node failed? |
Covers workflow execution records only |
|
Did an API request made by the current user succeed? |
Covers operation records for the current user in the current workspace only |
|
Which exceptions require proactive notifications, who is notified, and what has been triggered in the past? |
Alert rules, notification recipients, and alert records |
These three record types complement one another but should not be used interchangeably. SQL History focuses on a single query, Jobs focuses on one workflow execution, and Operation Logs focuses on API requests and their results.
Common troubleshooting paths¶
When a workflow fails, pauses, or runs abnormally, first open Jobs to confirm the execution status, failure information, and node path.
To analyze the duration, result, or execution plan of a SQL statement, open SQL History.
If you suspect an API request, permission, or submitted parameter caused the issue, open Operation Logs and review the request method, status code, and details.
For load-task issues, first check the task configuration and runtime information under Load Tasks. The Jobs entry on this page does not aggregate all load tasks.
Alert configuration and handling¶
Alerts consist of alert rules, notification recipients, and alert records. Create notification recipients first, then create rules, and finally use alert records to review triggers and fine-tune thresholds and notification intervals.
After receiving an alert, first confirm the rule, expression, and time in the alert record. Then open Jobs, SQL History, or Operation Logs to locate the specific cause. A read status only means someone viewed the record; it does not mean the problem has been resolved.
Scope¶
This guide does not cover standalone dashboards, platform system logs, Genesis model-service usage, or MatrixOne instance monitoring. It covers only monitoring, alerts, and exception investigation within an AI Studio workspace.
What this guide includes¶
Page |
Content |
|---|---|
Query list, filters, details, execution plans, result preview, and download |
|
Workflow execution list, details, status, and reruns |
|
API operation records, filters, and request details for the current user |
|
Alert rules, notification recipients, alert records, and handling workflow |