Monitoring

Alert Policies

An alert policy is a reusable set of alert rules you define once and assign across your project — to whole environments, API specs, or individual monitors — instead of configuring alerts on every monitor by hand. Manage them under Monitoring → Alert Policies. Creating and editing policies requires the monitoring:write permission.

Alert types

Every rule belongs to one of four alert types, each with its own condition:

Alert type Fires when Settings (defaults)
Downtime A run of consecutive checks fail. Consecutive failures (3)
Latency Threshold Average response time over a window of checks exceeds a limit. Threshold in ms (2000), window in checks (5)
Error Rate The share of failing checks in a window crosses a percentage. Threshold in % (50), window in checks (10)
Schema Drift Drift of at least a chosen severity is detected. Minimum severity (Error; also Warning, Info)

The minimum severity on the Schema Drift rule is what decides how sharp a drift alert is: Error covers the breaking changes — a required field gone missing, a type that changed — while Warning also fires on deviations such as fields the spec doesn't mention. See Contract Drift.

Every rule also has a cooldown — the minimum number of minutes between repeat alerts (default 30) — so a sustained problem doesn't flood you with notifications.

Creating a policy

  1. Open Alert Policies and click New Policy.
  2. Give it a Name (e.g. Critical Alerts) and an optional Description.
  3. Click Add Rule and configure the rule's type, condition, and cooldown. A policy holds at most one rule per alert type (up to four rules) and needs at least one rule to be saved.
  4. Click Create Policy.

When editing an existing policy, the dialog additionally shows an Enabled switch — disabled policies stop alerting everywhere they're assigned and can't be newly assigned.

Each policy card in the list shows its rule types, its assignment count, and — where applicable — a Default or Disabled badge. The policy marked Default applies automatically to monitors that have no other assignment, and it cannot be deleted; deleting any other policy also removes all of its assignments.

The Alert Policies page with a policy dialog open

Assigning policies

You assign a policy at three scopes from the monitor tree on the Monitors page: right-click an environment, an API spec, or a single monitor and choose Assign Alert Policy. Only enabled policies appear in the picker; the default policy is labeled (Default).

Because a monitor can be covered by assignments at more than one level, Routebase resolves an effective policy per monitor with the most specific scope winning: a direct monitor assignment beats its spec, which beats its environment, which beats the project default. When an incident opens, its detail shows which policy triggered it (Policy: …).

Note that the winning policy replaces the less specific one entirely rather than merging with it. A spec-scoped policy with only a drift rule therefore leaves that spec's monitors with no downtime alerting at all — which is why the one Routebase creates for you brings its own downtime rule along.

The "Contract Drift Watch" policy

If you find a policy by that name in the list without having created it, drift watch made it. Choosing Any contract deviation as the alert sharpness there needs a warning-severity drift rule, and the seeded default policy alerts on errors only — so a spec-scoped policy is created and assigned to that specification, carrying two rules:

  • Schema Drift at warning severity, 60-minute cooldown — the reason it exists.
  • Downtime after 3 consecutive failures — a mirror of the default rule, present because a spec-scoped policy replaces the project default wholesale.

Choosing Breaking changes only creates nothing; the default policy already covers error-severity drift, and drift watch never modifies it. Re-running the dialog with a different sharpness updates the same policy instead of adding a second one, and disabling drift watch leaves it in place — without validation results its drift rule cannot fire anyway.

Per-monitor custom alerts

When one monitor needs something its policy doesn't cover, add rules directly on the monitor: open the monitor's detail page, switch to the Alerts tab, and click Add Rule. The New Alert Rule dialog offers the same four alert types with slider-based conditions:

Alert type Ranges
Downtime Consecutive failures 1–10
Latency Threshold Threshold 100–30000 ms, window 1–20 checks
Error Rate 1–100%, window 5–50 checks
Schema Drift Minimum severity Error / Warning / Info

Cooldown is set in 5-minute steps from 5 to 120 minutes. Each rule in the list shows its current state — Idle, Firing, or Acknowledged — and when it last fired. Click a rule to edit it (you can toggle Enabled and adjust the cooldown) or use the trash icon to delete it.

Below the rules, Alert History lists past firings with when each alert fired, when it resolved, and how long it lasted.

A monitor's Alerts tab with alert rules and history

How alerts reach you

Fired alerts and the incidents they open appear in the in-app notification center under the Monitoring category. Whether you also get them by email is controlled per category in your notification preferences.

They can also land in a chat channel. Slack and Microsoft Teams are first-class delivery targets with their own Contract drift, Monitor incident and Monitor recovered categories, formatted for the client rather than posted as raw JSON — a drift alert arrives with the affected route, the concrete changes and a link straight back into Routebase. Set one up under Settings → Messaging; see Messaging.