> ## Documentation Index
> Fetch the complete documentation index at: https://docs.warrn.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Route alerts without paging

> Forward a chosen set of alerts to Slack or a webhook, with or without paging the on-call.

Not every alert deserves a page. Some should land in a Slack channel or another tool so the right people see them, without waking up whoever is on call. An alert rule can do exactly that: pick the alerts you care about and send them where they need to go.

A common case: one CloudWatch integration receives every alarm from an AWS account, and you only want the production database alarms in `#database-alerts`.

## Set it up

<Steps>
  <Step title="Have a source and a destination">
    You need an incoming integration that produces the alerts (CloudWatch, Grafana, Sentry, the Incoming API, and so on) and at least one place to send them: a Slack channel or an outgoing webhook. Both are configured on the team or one of its services. See [Slack](/integrations/slack) and [Outgoing Webhooks](/integrations/webhooks).
  </Step>

  <Step title="Create the rule">
    Open the team, go to **On-Call**, expand **Alert Rules**, and select **Add Rule**.

    1. Under **Integration scope**, pick the integration the alerts come from. Leave it empty to match alerts from any integration.
    2. Add conditions that describe the alerts you want. Match on the alert's name, severity, tags, or any of its details.
    3. Set **External notifications** to **Send only to selected destinations** and pick your Slack channels or webhooks.
    4. Set **On-call paging** to **Do not page anyone** if these alerts should not page.
  </Step>

  <Step title="Check it">
    Trigger a matching alert from the source. It shows up under **Alerts → Routed** with the rule that matched it and where it was sent.
  </Step>
</Steps>

## Example

Send production RDS alarms to Slack and a webhook, without paging:

| Setting                | Value                                                                              |
| ---------------------- | ---------------------------------------------------------------------------------- |
| Integration scope      | Production CloudWatch                                                              |
| Conditions             | Name starts with `database-`, and Metadata `cloudwatch_namespace` equals `AWS/RDS` |
| External notifications | Send only to selected destinations                                                 |
| Destinations           | `#database-alerts`, Operations webhook                                             |
| On-call paging         | Do not page anyone                                                                 |

Everything else from that integration keeps flowing to the rules below it and, if nothing matches, to the team's normal paging.

## Notifications and paging are separate choices

Every rule makes two decisions on its own:

* **External notifications**: use the team's usual destinations, send only to the ones you picked, or send nothing.
* **On-call paging**: page as usual, or do not page anyone.

So you can notify Slack and still page, notify without paging, or page without any external notification. To drop an alert entirely, use the **Suppress Alert** action instead.

<Note>
  Routes apply when an alert fires or fires again. Acknowledging or resolving an alert in Warrn is not forwarded to the destination.
</Note>

## Where routed alerts show up

Alerts that were routed without paging live in **Alerts → Routed**. They are kept out of the Active and Open queues so those stay focused on what needs a person, but they are always in **All Alerts** and search. Each one shows whether the source is still firing and records that it was routed without paging.

## Good to know

* **Rules run top to bottom, first match wins.** Put specific routes above broad ones.
* **Destination severity filters still apply.** If a Slack channel is set to only receive high and critical, a medium alert routed to it is skipped.
* **A failed delivery does not fall back to paging.** Check the destination's **Observability** tab to see recent deliveries and any errors.