Skip to main content

Policies & Conditions

Policies define what you want to be alerted on and when. Each policy evaluates metrics or events against one or more conditions and, when they match, creates an alert that flows through routes and escalation chains.

This guide explains how to design effective alert policies for Unified Monitoring.

Policy Building Blocks​

  • Scope – which resources or series the policy applies to (for example, a specific application, account, or service).
  • Signal type – metrics, events, or a combination.
  • Condition – threshold, rate‑of‑change, absence‑of‑data, or comparison between metrics.
  • Window – how much history to consider (for example, last 5 minutes, last 1 hour).
  • Severity – e.g., info, warning, critical.

Common Condition Types​

  • Static threshold – metric is above/below a value for some period (for example, CPU > 80% for 10 minutes).
  • Rate of change – metric changes too fast (for example, error rate doubles within 5 minutes).
  • Relative to baseline – metric deviates from its usual pattern (for example, traffic is significantly lower than typical for this time of day).
  • Absence of data – expected metrics or heartbeats stop arriving.
  • Event‑based – specific events or combinations of events occur (for example, a Zabbix trigger fires or a third‑party incident is opened).

Best Practices​

  • Tie policies to business outcomes where possible (for example, user‑visible error rate) rather than low‑level resource metrics only.
  • Use multiple severities to distinguish between early warnings and urgent issues.
  • Avoid duplicate policies that alert on the same symptom through different paths.
  • Include clear descriptions and runbook links in alert messages.

Testing and Rollout​

  • Start policies in warning or “notify only” mode to gauge noise.
  • Use limited scopes (for example, a single environment) before expanding to production.
  • Review policy performance regularly and retire rules that do not add value.