> ## Documentation Index > Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt > Use this file to discover all available pages before exploring further. # Alert Rules > Advanced XIMP alert rule configuration — compound conditions, silences, inhibition rules, on-call escalation, and GitOps-based rule management. ## Overview This page covers advanced alert rule configuration beyond basic threshold alerts — including compound multi-condition rules, silencing active alerts during maintenance windows, inhibition rules that suppress lower-severity alerts when a critical one is already firing, and escalation policies. **Prerequisites** * An active Xloud account with project access * At least one notification channel configured (see [XIMP Admin — Alert Channels](/services/monitoring/admin-guide/alert-channels)) *** ## Compound Alert Rules Combine multiple conditions in a single rule using AND/OR logic: Navigate to **Monitor Center > Monitoring** (Create Alert Rule, admin view) and click **Advanced Mode**. In Advanced Mode, add multiple conditions: | Field | Value | | --------------- | ------------------------------------ | | **Condition A** | `xloud_compute_cpu_utilization > 85` | | **Operator** | `AND` | | **Condition B** | `xloud_compute_memory_free_pct < 15` | This rule fires only when both CPU is above 85% AND available memory is below 15% — reducing false positives from transient CPU spikes. ```yaml title="alert-resource-pressure.yaml" theme={null} name: resource-pressure-critical severity: critical evaluation_period: 5m conditions: - metric: xloud_compute_cpu_utilization condition: ">" threshold: 85 - metric: xloud_compute_memory_free_pct condition: "<" threshold: 15 logic: AND notification_channels: - ops-pagerduty ``` ```bash title="Create compound alert rule" theme={null} ximp alert rule create --file alert-resource-pressure.yaml ``` *** ## Silencing Alerts Silences temporarily suppress alert notifications during planned maintenance. The alert rule continues to evaluate — only notifications are suppressed. Navigate to **Monitor Center > Monitoring** (Create Silence, admin view). | Field | Description | | ------------ | ------------------------------------------------------------------------------- | | **Matchers** | Label selectors that match the alerts to silence (e.g., `host=compute-node-03`) | | **Duration** | How long the silence is active (e.g., `2h`) | | **Comment** | Reason for the silence (required — links to change ticket) | | **Creator** | Your username (auto-populated) | Navigate to the Silences section in **Monitor Center > Monitoring**. Active silences show their matcher, creator, and expiry time. Any alerts matching the silence matchers show status `Silenced` instead of firing notifications. ```bash title="Create a 2-hour silence for a host" theme={null} ximp alert silence create \ --matcher 'host=compute-node-03' \ --duration 2h \ --comment "Scheduled maintenance window - firmware update" ``` ```bash title="List active silences" theme={null} ximp alert silence list --status active ``` ```bash title="Expire a silence early" theme={null} ximp alert silence expire ``` *** ## Inhibition Rules Inhibition rules suppress lower-severity alerts when a higher-severity alert is already active for the same source. This prevents alert storms during major incidents. ```yaml title="Example: Suppress warnings when critical is firing" theme={null} inhibit_rules: - source_matchers: - severity="critical" target_matchers: - severity="warning" equal: - host ``` This rule suppresses all `warning` alerts for a host when a `critical` alert is already firing for that same host — reducing notification noise during a major outage. Configure inhibition rules via **Monitor Center > Monitoring** (Inhibition Rules, admin view). *** ## Escalation Policies Configure multi-tier escalation for critical alerts: Navigate to **Monitor Center > Monitoring** (Escalation Policies, admin view). | Tier | Channel | Delay | Condition | | ------ | -------------------- | ---------- | -------------------- | | Tier 1 | PagerDuty on-call | Immediate | Alert fires | | Tier 2 | Slack ops channel | 5 minutes | Not acknowledged | | Tier 3 | Page on-call manager | 15 minutes | Still unacknowledged | Open an existing alert rule and set the **Escalation Policy** field to the policy you created. The policy applies to all future alert events for that rule. Create separate escalation policies for different severity levels — critical infrastructure alerts may warrant a 3-tier escalation while informational alerts can go to a single team Slack channel with no escalation. *** ## GitOps-Based Rule Management Manage alert rules as code for version-controlled, auditable configurations: ```bash title="Export all current alert rules" theme={null} ximp alert rule export --format yaml --output ./alert-rules/ ``` ```bash title="Import rules from directory" theme={null} ximp alert rule import --dir ./alert-rules/ --apply ``` Store rule files in your infrastructure repository and apply changes through your CI/CD pipeline. This enables peer review of alert rule changes and automatic rollback if a rule causes issues. *** ## Next Steps Basic alert rule creation for metric thresholds Configure the notification channels referenced by alert rules Visualize metrics alongside alert thresholds Diagnose alert rules that are not firing or delivering notifications