# Monitoring views

Monitoring at scale reduces the time required to monitor Foundry resources by introducing enhanced capabilities. Monitoring views are a collection of monitoring rules and health checks.

Monitoring views offer expanded functionality beyond what is available in check groups and we recommend [upgrading all existing check groups](#upgrade-an-existing-check-group-to-a-monitoring-view) to monitoring views.

With monitoring views, you can monitor the following resource types:

| Resource type  | Supported scope |
| ------------------------------|:-------------------:|
| [Agent](../rules-reference/index.md#agent-rules)                                   | Single, Project     |
| [Object type](../rules-reference/index.md#object-and-link-rules)                   | Single, Project     |
| [Link type](../rules-reference/index.md#object-and-link-rules)                     | Single, Project     |
| [Schedule](../rules-reference/index.md#schedule-rules)                             | Single, Project     |
| [Streaming dataset](../rules-reference/index.md#streaming-dataset-rules)          | Single, Folder, Project |
| [Live deployment](../rules-reference/index.md#live-deployment-rules)              | Single     |
| [Time series sync](../rules-reference/index.md#time-series-sync-rules)               | Single           |
| [Geotemporal observation](../rules-reference/index.md#geotemporal-observation-rules) | Single           |
| [Automation](../rules-reference/index.md#automation-rules)                           | Single, Project  |
| [Dataset](../rules-reference/index.md#dataset-rules)                     | Single, Folder, Project |
| [Function](../rules-reference/index.md#function-rules)                     | Single, Project, Workflow Lineage, Workshop, OSDK application  |
| [Action type](../rules-reference/index.md#action-rules)                     | Single, Project, Workflow Lineage, Workshop, OSDK application  |

If you need detailed content and schema validation, consider using [health checks](../../health-checks/overview/index.md).

## Create a new monitoring view

To create a new monitoring view, navigate to the **Monitoring View** tab in the top right corner of the **Data Health** application and select **New monitoring view**.

### Add a monitoring rule

In your new monitoring view, you can **Add monitoring rules** on the **Manage monitors** tab. First, select the resource type you are looking to monitor and then select a scope.

With a **static** scope, you select a specific resource to monitor. With a **dynamic** scope, the monitor automatically updates as resources are added or removed, without requiring manual changes. Dynamic scopes include **Folder**, **Project**, **Workflow Lineage**, **Workshop**, and **OSDK application**, though availability varies by resource type. See the [supported scope table](#monitoring-views) for details.

To use project scope with ontology resources, you must first [migrate your ontology to project-based permissions](../../ontology-manager/migrate-to-project-based-permissions/index.md).

Some monitoring rules have multiple conditions joined by `AND`. For these composite rules, configure a threshold for each condition at every alert severity. The rule triggers only when all conditions reach that severity. If the conditions reach different severities, the rule triggers at the lowest severity reached by all conditions.

![Data Health application showing the monitoring rule creation wizard with dynamic scope options for action types.](../../../assets/a70d6dfe989badbe1fbce9afcc9eb537074419299e998dcf65279d6acb2e9ce5.webp)

:::callout{theme="warning"}
You must have `Viewer` permission on the resources to monitor them. To [receive alerts](#subscribe-to-alerts) triggered by monitoring rules, you must have `Viewer` permission on the resources and the monitoring view.
:::

Additionally, you can [review the Monitoring rules resource reference](../rules-reference/index.md).

### Configure monitors

Monitors are set on the metrics emitted by a resource. As you set up your monitors, we suggest certain configurations based on Foundry’s standards for health. However, you can change the values or choose to only monitor certain metrics. You can also determine the level of severity for the alert: low, medium, and high.

### Edit monitors

You can edit your monitors by selecting from the list of monitors and choosing **Edit** on the side panel that appears.

### Add existing health checks

You can add existing health checks to a monitoring view from the **Data Health** application:

1. Open the monitoring view and select **Add health check** in the top-right corner.
2. In the **Add health checks** dialog, use the filters or search for a dataset to find the health checks you want to add.
3. Select one or more health checks, then select **Add checks**. The selected health checks are added to the monitoring view.

![The Add health checks dialog listing existing health checks that can be added to a monitoring view.](../../../assets/47fe152c5e453ad9601feae66cd7f27edc39da35ffdaadd438a46ced4a3b5b1d.webp)

This dialog only adds health checks that already exist. To create a new health check, add it to a dataset from the [**Health** tab](../../health-checks/overview/index.md#health-tab). To create the same health check on multiple datasets at once, refer to [Add new health checks to multiple datasets](../../health-checks/overview/index.md#add-new-health-checks-to-multiple-datasets).

## Set up and manage alert notifications

Once you have configured your monitoring rules, you will need to set up how and where alerts are delivered when issues are detected.

### Subscribe to alerts

To subscribe to alerts, navigate to the **Manage subscriptions** tab where all the subscribed users are listed. You can add users and user groups, and configure their alerts based on severity. When a monitor rule triggers an alert, the user subscribed to the monitoring view containing that alert will be notified via email and Foundry notifications. You must have `Viewer` permission on the resources and the monitoring view to receive alerts.

### Integrate with external systems

You can send alerts to external systems such as PagerDuty or Slack with built-in integrations or by using a webhook to hit arbitrary REST endpoints. Learn more about [sending alerts to external systems](../external-systems/index.md).

## Troubleshoot alerts

On the **Troubleshoot alerts** tab, you can review your alerts by alert name, resource, failure reason, and the time of reported alert. Additionally, you can **view options**, **group by project**, or **filter by type** (for checks only).

![Troubleshoot alerts in one place, using the Data Health application.](../../../assets/3ef96ace666566d17db7e51ed6d88eb9b2558b933582be267ef6642721c1c6b2.webp)

For individual monitor rules, you can open the [alert debug page](../alert-debug-page/index.md) to view detailed metrics, alert history, and diagnostic information.

### Snooze alerts after they fire

You can snooze an individual alert after it fires for both health checks and monitors to temporarily suppress notifications. To snooze an alert, select it from the **Troubleshoot alerts** panel and choose **Snooze** from the toolbar displayed in the bottom of your screen. Additionally, you can select the bell icon in the **About** tab of the **Context Panel** that renders after you select the alert. Configure a suspension duration and provide a reason for snoozing before selecting **Snooze**.

![Snooze fired alerts in the Troubleshoot alerts tab.](../../../assets/d5cd83493ac40969d87a9b0c41142544a1ebf7c75c3f47118d1243fc45096935.webp)

Snoozed alerts contain an inline bell icon tag that displays who snoozed the alert, when, and why upon hover. Use the **Hide snoozed alerts** toggle in the top right to hide snoozed alerts from view. Once hidden, a banner in the footer of the **Troubleshoot alerts** panel displays the number of currently snoozed alerts.

![Hover details for snoozed alerts in the Troubleshoot alerts tab.](../../../assets/05f1107cf131660becb869ae02fca150c86d83a289b8af4e54ddd6922b128524.webp)

To resume an alert's notifications, select **Unsnooze** from the toolbar at the bottom of your screen or wait for the snooze duration to expire.

Unlike health check alerts, snoozed monitor alerts remain snoozed even if they re-fire.

### Snooze monitor rules

In addition to snoozing individual alerts, you can snooze an entire monitor rule to silence alerts across all targets within that rule's scope at once. This is particularly useful when you are aware of a known issue and want to suppress all alerts tied to a particular rule in a single action.

To snooze a monitor rule, navigate to the **Manage monitors** tab in your monitoring view, select the rule you want to snooze, and choose **Snooze** from the available actions.

:::callout{theme="warning"}
When you snooze a monitor rule, any existing target-level snoozes for that rule will be replaced by the new rule-level snooze.
:::

### Navigate to resource lineage from an alert

From an alert on the **Troubleshoot alerts** tab or the [alert debug page](../alert-debug-page/index.md), you can navigate directly to the resource's lineage view.

* Datasets, schedules, and object types will open in Data Lineage.
* Functions, action types, and automations will open in Workflow Lineage with the **Run history** tab selected.

![Run history button for an action type in the Troubleshoot alerts tab.](../../../assets/025b46239eb0038d5e7029d644213f6930798aa4fe7420867bd820672e1c3753.webp)

For function and action type monitoring rules, pre-filters are automatically applied to the run history based on the monitor rule type to surface the most relevant executions. Pre-filtered run history navigation is currently available for these resource types only.

| Rule type | Run time range | Status | Timestamp range | Failure reason |
| --------- | -------------- | ------ | --------------- | -------------- |
| **Duration p95** | Set to the monitor's threshold value, showing only executions that exceeded the threshold. | — | — | — |
| **Number of failures in window** | — | Set to **Failed** | Start of the monitor's time window at the time the alert fired. | — |
| **Number of user-facing failures in window** | — | Set to **Failed** | Start of the monitor's time window at the time the alert fired. | Set to **User facing error** |

## Monitoring status in Workflow Lineage

While monitoring alerts inform you that a specific monitor is firing, you can also view monitoring coverage across a whole workflow. To do this, open the workflow as a graph in [Workflow Lineage](../../workflow-lineage/overview/index.md), select the color legend, and choose **Monitoring status** under **Health**. Each node is colored by the highest severity among the monitors currently firing against that resource.

![A Workflow Lineage graph colored by monitoring status, with the legend showing a count for each status.](../../../assets/102e70a64bda449d163eedb18fc71e4221a8197b28fd65fea4722688796fab58.webp)

### Monitoring status legend keys

| Legend key | Meaning |
| --- | --- |
| `All monitors healthy` | The resource has monitors, and none of them are firing. |
| `Low severity` | The highest firing severity on the resource is `Low`. |
| `Medium severity` | The highest firing severity on the resource is `Medium`. |
| `High severity` | The highest firing severity on the resource is `High`. |
| `No monitors configured` | The resource can be monitored, but no monitoring rules target it. |
| `Not applicable` | The resource cannot be the target of a monitoring rule. |

Severity levels are the same `Low`, `Medium`, and `High` levels you set when you [configure monitors](#configure-monitors). Use `No monitors configured` to find gaps in coverage; a node with that key is a resource in your workflow that no monitoring view is watching.

### How status is determined

Three behaviors are worth understanding when reading the colors:

* Only firing monitors affect the color. A resource with several monitors takes on the highest-severity level among those currently firing.
* A monitoring rule that has not yet computed its status for the first time is treated as healthy, so a newly created rule will not color its target until it has run.
* AIP Logic nodes take the status of their backing function. A monitor set on the function colors the Logic node that uses it.

:::callout{theme="warning"}
Monitoring status is based on the highest severity alert in the monitoring views you have access to. A resource may have additional alerts that are not visible to you.
:::

The monitoring status color mode requires monitoring views to be available on your enrollment. If they are not available, the option does not appear in the Workflow Lineage color legend.

## Upgrade an existing check group to a monitoring view

To upgrade an [existing check group](../check-groups/index.md), open your check group in the **Data Health** application. In the top banner, select **Upgrade to monitoring view**.

You can create a new monitoring view or move all the checks to an existing monitoring view.

:::callout{theme="success"}
* Monitoring views are filesystem resources. If you are creating a new monitoring view, be sure to store it in a project accessible to potential subscribers.
* After upgrading your check group, checks will continue to be supported exactly as they are now. There are no changes to email digest, alerting, subscriptions, or any other workflow related to health checks.
* Each check group can be linked to a single monitoring view and vice versa; therefore, you can only upgrade one check group to a single existing monitoring view, or create a new monitoring view if a suitable one does not exist.
:::