> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/ai-sre/3.0/ai-sre-for-administrators/set-up-on-call-management/configure-alert-rules.md).

# Configure Alert Rules

Alert rules connect incoming monitoring alerts to the correct on-call team.

When an alert fires, AI SRE evaluates your rules to determine whether to page a responder and which escalation policy to use.

### Create an alert rule <a href="#create-an-alert-rule" id="create-an-alert-rule"></a>

Follow these steps to create an alert rule that routes alerts to an on-call team:

1. Navigate to **On-Call** → **Route Alerts**.
2. Click **Create Alert Rule**.
3. Configure the rule:
   * **Name:** A descriptive name (for example, "Payments Alerts → Payments On-Call").
   * **Service:** Select the service this rule applies to. The service list is populated from the [service directory](/ai-sre/ai-sre-for-administrators/set-up-on-call-management/integrate-service-directory.md).
   * **Paging toggle:** Enable to automatically page the on-call responder when this rule matches. Disable to log the alert without paging.
   * **Escalation policy:** Select which escalation policy to invoke when this rule triggers.
4. Click **Save**.

***

### How alert routing works <a href="#how-alert-routing-works" id="how-alert-routing-works"></a>

AI SRE routes an incoming alert to a responder through the following steps:

1. An alert arrives from a monitoring integration (Datadog, New Relic, Grafana, and similar).
2. AI SRE extracts the **impacted service** from the alert payload.
3. The system evaluates your route alerts to find a **matching service**.
4. If the matching rule has paging enabled, the **escalation policy** is invoked, which identifies the current on-call responder and sends notifications.

If no alert rule matches the incoming service, the alert is logged but no page is triggered.

***

### Configure default and impacted services <a href="#configure-default-and-impacted-services" id="configure-default-and-impacted-services"></a>

Each alert rule can be configured with:

* **Default service:** The service assumed if the alert payload does not include a service identifier.
* **Impacted service:** Extracted automatically from the alert payload when available, overriding the default.

This lets you handle both well-structured alert payloads and those that lack service metadata.

***

### Best practices <a href="#best-practices" id="best-practices"></a>

Follow these practices to keep alert routing reliable:

* **Create specific rules per service:** Broad, catch-all rules risk paging the wrong team. Map each production service to its own alert rule.
* **Be deliberate with the paging toggle:** Not every alert should wake someone up. Enable paging only for alerts that require immediate human attention. Use the toggle to suppress paging for informational or low-severity alerts.
* **Align rules with your service directory:** Alert rules rely on service mappings. If a service is not in the directory or is mapped to the wrong team, routing fails silently.
* **Test end-to-end:** Send a test alert from your monitoring tool and verify that it matches the correct rule, pages the right person, and uses the expected escalation policy.
* **Review rules regularly:** As services are added, renamed, or retired, update your route alerts to stay in sync.

***

### Next steps <a href="#next-steps" id="next-steps"></a>

* Go to [Integrate with the Service Directory](/ai-sre/ai-sre-for-administrators/set-up-on-call-management/integrate-service-directory.md) to map services to on-call teams.
* Go to [Configure Escalation Policies](/ai-sre/ai-sre-for-administrators/set-up-on-call-management/define-escalation-policies.md) to define the escalation chains that alert rules invoke.