# 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 |
| --- | --- | --- |
| [SQL Execution Records](sql-history.md) | 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 |
| [Jobs](jobs.md) | What is the status of a workflow execution, and which node failed? | Covers workflow execution records only |
| [Operation Logs](logs.md) | Did an API request made by the current user succeed? | Covers operation records for the current user in the current workspace only |
| [Alerts](alerts.md) | 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 Execution Records focuses on a single query, Jobs focuses on one workflow execution, and Operation Logs focuses on API requests and their results.

## Common troubleshooting paths

1. When a workflow fails, pauses, or runs abnormally, first open [Jobs](jobs.md) to confirm the execution status, failure information, and node path.
2. To analyze the duration, result, or execution plan of a SQL statement, open [SQL Execution Records](sql-history.md).
3. If you suspect an API request, permission, or submitted parameter caused the issue, open [Operation Logs](logs.md) and review the request method, status code, and details.
4. For load-task issues, first check the task configuration and runtime information under [Import Tasks](../data-sources/load-tasks.md). The Jobs entry on this page does not aggregate all import tasks.

## Alert configuration and handling

[Alerts](alerts.md) 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](jobs.md), [SQL Execution Records](sql-history.md), or [Operation Logs](logs.md) 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 |
| --- | --- |
| [SQL Execution Records](sql-history.md) | Query list, filters, details, execution plans, result preview, and download |
| [Jobs](jobs.md) | Workflow execution list, details, status, and reruns |
| [Operation Logs](logs.md) | API operation records, filters, and request details for the current user |
| [Alerts](alerts.md) | Alert rules, notification recipients, alert records, and handling workflow |

## Documentation tree

```{toctree}
:hidden:
:maxdepth: 1

SQL execution records <sql-history>
Jobs <jobs>
Logs <logs>
Alerts <alerts>
```