Skip to main content
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.
  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.
  3. A monitor fires. The alert is investigated and graded before anything reaches Slack. See Triage.
  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.
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: Alerts from these monitors show up on the Episodes page, one row per problem, and in the Slack channels you route them to.