---
title: 'Synthetic Monitoring Alerts'
description: 'Multi-location correlation, cross-monitor dependency detection, and alert triage with full OTel context. Signal instead of noise.'
canonical_url: 'https://yorkermonitoring.com/features/alerting'
---

# Alerts that correlate

Triage that explains

Signal, not noise.

Single-location failures are noise. Yorker correlates across locations, detects shared dependency failures across monitors, and attaches full OTel context to every alert.

[Start Free](/sign-up) | [Read Docs](/docs)

```yaml
# yorker.config.yaml
# excerpt; @ops-slack and @pagerduty-oncall are
# defined in the alertChannels block (see /docs/guides/notification-channels)
monitors:
  - name: Checkout Flow
    type: browser
    script: ./monitors/checkout.ts
    alerts:
      - conditions:
          - type: multi_location_failure
            minLocations: 2
            windowMinutes: 5
        channels:
          - "@ops-slack"

  - name: API Health
    type: http
    alerts:
      - conditions:
          - type: consecutive_failures
            count: 3
        channels:
          - "@pagerduty-oncall"
```

## How it works

### 01. Failure detected at one location

A check fails at a single location. Not yet actionable: geographic noise is common.

### 02. Multi-location correlation

Yorker checks whether N of M configured locations confirm the failure within the time window.

### 03. Cross-monitor pattern detection

Whether other monitors share the same failure signature, indicating a shared dependency rather than an isolated issue.

### 04. Alert fired with OTel context

One alert, with the OTel trace link, recent results context, and triage summary attached.

## Multi-location correlation

Only alert when N of M configured locations confirm the failure within a configurable time window. A single location failure in Singapore at 3am is noise. The same failure confirmed from Singapore, Tokyo, and Sydney is a real incident.

Configurable per monitor. A critical payment endpoint might require 2 of 3 locations. A less critical health check might require 3 of 5.

### Location correlation: Checkout Flow

| Location | Time | Status |
| --- | --- | --- |
| Tokyo | 14:02:31 | fail |
| Singapore | 14:02:34 | fail |
| Sydney | 14:02:37 | fail |
| London | 14:02:32 | pass |
| Frankfurt | 14:02:35 | pass |

Threshold met: 3 of 3 Asia-Pacific locations. Alert firing to #ops-incidents.

## Cross-monitor pattern detection

When multiple monitors degrade with a shared signature, Yorker surfaces the pattern. One shared dependency alert instead of six separate monitor alerts to correlate manually at 2am.

The alert tells you which monitors are affected, what the shared dependency is, and how many locations confirm the pattern, not just that something broke.

### Cross-monitor pattern: active incident

| Monitor | Status |
| --- | --- |
| Checkout Flow | degraded |
| Product Detail | degraded |
| Homepage | degraded |
| Search Results | degraded |

Shared dependency: cdn.tagmanager.net. 4 monitors, 1 alert fired (not 4).

## Alert triage and context

(Paid plan)

Every alert carries the OTel trace link, recent results context, and a triage summary with root cause hypothesis and recovery outlook. Not just a notification that something broke: context for what to do about it.

- OTel trace link in every alert: one click to the distributed trace
- Recent results context: how long has this been failing?
- Root cause hypothesis based on cross-monitor correlation
- Recovery outlook: is it getting better or worse?

### Alert triage summary

**Root cause hypothesis**

cdn.tagmanager.net responding 3.2× slower than baseline. 4 monitors share this dependency. No CDN incident reported.

**Context**

Failing for 12 minutes across 3 Asia-Pacific locations. European and North American locations passing.

**Recovery outlook**

Degradation increasing. Last 3 runs show worsening LCP deviation.

## Unlike webhook-based alerting

- Most tools fire an alert per monitor per location. Yorker correlates before alerting, so you get one signal with context, not a flood of notifications requiring manual correlation.
- OTel trace linking means every alert has a direct link to the backend trace showing what happened on your infrastructure at the same moment as the synthetic failure.
- Alert triage provides a root cause hypothesis and recovery outlook based on recent results and check context, not just a raw notification that something failed.

## Related features

### OpenTelemetry

The OTel insight packs that give every alert its full context.

[/features/opentelemetry](/features/opentelemetry)

### Browser Monitoring

Browser check intelligence that surfaces cross-monitor dependency failures.

[/features/browser-monitoring](/features/browser-monitoring)

### SLO Tracking

Error budgets and burn rate alerting on your synthetic monitors.

[/features/slo-tracking](/features/slo-tracking)

## Frequently asked questions

### When does Yorker fire an alert instead of treating a failure as noise?

A single location failure is treated as noise, because geographic noise is common. Yorker only alerts when N of M configured locations confirm the failure within a configurable time window. For example, a failure confirmed from Singapore, Tokyo, and Sydney is a real incident, while the same failure at a single location at 3am is not yet actionable.

### Can I tune the correlation threshold per monitor?

Yes. Multi-location correlation is configurable per monitor. A critical payment endpoint might require 2 of 3 locations, while a less critical health check might require 3 of 5.

### What happens when several monitors break at once?

When multiple monitors degrade with a shared signature, Yorker surfaces the pattern and fires one shared dependency alert instead of separate monitor alerts to correlate manually. The alert tells you which monitors are affected, what the shared dependency is, and how many locations confirm the pattern. In the example incident, four monitors share cdn.tagmanager.net and a single alert is fired (not four).

### What context comes attached to an alert?

Every alert carries the OTel trace link, recent results context, and a triage summary with a root cause hypothesis and recovery outlook. That includes a one-click link to the distributed trace, how long the issue has been failing, a root cause hypothesis based on cross-monitor correlation, and whether the situation is getting better or worse. Alert triage and context is available on the paid plan.

### How is this different from webhook-based alerting?

Most tools fire an alert per monitor per location. Yorker correlates before alerting, so you get one signal with context rather than a flood of notifications requiring manual correlation. OTel trace linking gives every alert a direct link to the backend trace showing what happened on your infrastructure at the same moment as the synthetic failure. And alert triage provides a root cause hypothesis and recovery outlook based on recent results and check context, not just a raw notification that something failed.

## Put your first check live in one command.

Free tier includes 10,000 HTTP + MCP checks and 1,500 browser checks per month. No credit card required.

```
npx @yorker/cli init
```

[Start Free](/sign-up) | [Read Docs](/docs)