---
title: "Issue Monitors and Alerts"
description: "Use Monitors to detect problems and create issues, and use Alerts to be notified when those issues change state or match your filters."
url: https://docs.sentry.io/product/issues/monitors-and-alerts/
---

# Issue Monitors and Alerts

[Monitors](https://docs.sentry.io/product/monitors-and-alerts/monitors.md) and [Alerts](https://docs.sentry.io/product/monitors-and-alerts/alerts.md) are used to customize issue detection and action. **Monitors** focus on *when* something becomes an issue; **Alerts** focus on *what to do next* (notify, ticket, webhook).

For the full product overview, see [**Monitors and Alerts**](https://docs.sentry.io/product/monitors-and-alerts.md).

## [How They Work Together](https://docs.sentry.io/product/issues/monitors-and-alerts.md#how-they-work-together)

**Monitors** watch signals you care about on top of default error detection,like scheduled jobs, URLs, metric thresholds on spans, and custom application metrics and create issues when their conditions are met. **Alerts** run when issues match the triggers and filters you configure, and carry out **actions** such as Slack messages, email, or creating work items in an integrated tool.

```mermaid
flowchart LR
  subgraph detect["Monitors"]
    M[Detect problems]
  end
  subgraph issues["Issues"]
    I[Issues are created by Monitors]
  end
  subgraph respond["Alerts"]
    A[Take action on issue events]
  end
  M --> I
  I --> A
```

Typical flow:

1. A **Monitor** detects a problem → Sentry creates or updates an **issue**.
2. An **Alert** whose sources (Monitors) and filters (conditions) match that issue → runs actions (notifications, tickets, webhooks).

Alerts can be scoped to **Projects** or **Monitors**, so you can set one alert for multiple monitors or projects that your team owns. You can also multiple alerts for one monitor for uses like differing alerting needs for multiple teams or environments.

## [Monitors](https://docs.sentry.io/product/issues/monitors-and-alerts.md#monitors)

Monitors define when errors, performance problems, or operational failures become issues you triage in Sentry. They include:

* **Custom monitors** for [metrics](https://docs.sentry.io/product/monitors-and-alerts/monitors.md#metric-monitor-settings), [cron jobs](https://docs.sentry.io/product/monitors-and-alerts/monitors/crons.md), and [uptime checks](https://docs.sentry.io/product/monitors-and-alerts/monitors/uptime-monitoring.md)
* **Default monitors** coming from your SDK integration like [issue grouping/fingerprint rules](https://docs.sentry.io/concepts/data-management/event-grouping.md)

[Learn more about monitor types](https://docs.sentry.io/product/monitors-and-alerts/monitors.md#types-of-monitors)

## [Alerts](https://docs.sentry.io/product/issues/monitors-and-alerts.md#alerts)

Alerts trigger when issue state or attributes match what you configure: for example, notify a Slack channel when a new issue appears, or open a Jira ticket when an issue is assigned and matches severity filters.

[Learn how to create and manage alerts](https://docs.sentry.io/product/monitors-and-alerts/alerts.md)

## [Getting Started](https://docs.sentry.io/product/issues/monitors-and-alerts.md#getting-started)

1. **Create or review [Monitors](https://docs.sentry.io/product/monitors-and-alerts/monitors.md)** for the signals you need (cron, uptime, metrics, defaults).
2. **Create [Alerts](https://docs.sentry.io/product/monitors-and-alerts/alerts.md)** with the right sources, triggers, filters, and actions.
3. **Add alerts to your team's workflow** at the project or monitor level to be notified when issues match your filters.

Learn more about configuring [Monitors and Alerts](https://docs.sentry.io/product/monitors-and-alerts/alerts.md) and [**Creating alerts**](https://docs.sentry.io/product/alerts/create-alerts.md).
