> ## Documentation Index
> Fetch the complete documentation index at: /docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Auto Monitors

> Monitors that create themselves from your pull requests and stay tuned as production changes.

Most teams have two problems at once: blind spots where nothing is watching, and a flood of alerts nobody reads. Both come from the same place. Monitors get set up once, then code moves on and nothing owns the upkeep.

Auto Monitors owns it. Ordyn reads every pull request, works out what that change needs watched in production, and creates the monitors once the change deploys. The monitors live in the tools you already use, such as Datadog, Sentry, AWS CloudWatch, Azure Monitor, or Google Cloud.

## What happens, change by change

1. **A pull request opens.** Ordyn reads the diff and posts one review listing the monitors it expects to create for this change. If the code does not emit the telemetry a monitor would need, Ordyn says exactly what to add and where. See [Pull requests](/detect/pull-requests).
2. **The change deploys.** Ordyn combines what it expected across every PR in the deploy, waits for real traffic, sets thresholds from real data, and creates the monitors. It also checks the deploy itself for regressions and traces any it finds back to the PR that caused them. See [Deploys](/detect/deploys).
3. **A monitor fires.** The alert is investigated and graded before anything reaches Slack. See [Triage](/triage/overview).
4. **Things change.** Ordyn re-checks its monitors on later deploys, folds duplicates, and adjusts or retires monitors that stop matching the code. See [Keeping monitors tuned](/detect/maintenance).

Ordyn works one change at a time. Turning it on does not scan your existing code or create anything until the next pull request opens.

## Where to look

The **Detect** page in the app has three tabs:

| Tab | What it shows |
| - | - |
| **Auto Monitors** | Every monitor Ordyn has created or plans to create, with its source PR, provider, and current state. |
| **Deploys** | Each deploy Ordyn verified, with regressions called out and the PRs involved. |
| **Pull requests** | Every PR Ordyn reviewed and what it found. |

Alerts from these monitors show up on the **Episodes** page, one row per problem, and in the Slack channels you route them to.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.