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

# Why did an alert post twice to a Slack channel?

> Find and remove the second notification path when one alert produces two Slack messages in the same channel

When one alert produces two messages in the same Slack channel, two separate
notification paths are almost always targeting that channel. This article shows
admins how to find both paths and decide which one keeps the channel.

## How alerts reach a Slack channel

Rootly can post an alert to a channel through several independent mechanisms,
and each one posts its own message:

* **Escalation policy steps** — an [escalation policy](/on-call/escalation-policies)
  level can notify a Slack channel directly.
* **Team Alert Broadcast** — a [team](/managing-teams/configuring-teams) can
  broadcast every alert routed to it into a channel.
* **Service Alert Broadcast** — each service can broadcast alerts on that
  service into a channel of its own.
* **Default alerts channel** — your [Slack integration](/integrations/slack/slack)
  can post every new alert to one workspace-wide channel.
* **Workflows** — an [alert workflow](/workflows/alert-workflows) can send Slack
  messages to any channel.

A duplicate post means two of these target the same channel. The two messages
often have different header text, because each mechanism formats its post
differently.

## Find the second path

<Steps>
  <Step title="Note the alert's team, services, and escalation policy">
    Open the alert in Rootly and note which team, services, and escalation
    policy it carries. These are where channel notifications come from.
  </Step>

  <Step title="Check the escalation policy">
    In the escalation policy editor, look for levels that notify the Slack
    channel directly. A policy with multiple paths can reference the same
    channel more than once.
  </Step>

  <Step title="Check the team's Alert Broadcast">
    On the team's edit page, check whether **Alert Broadcast** is enabled and
    which channel it targets.
  </Step>

  <Step title="Check each service's Alert Broadcast">
    On the edit page of every service attached to the alert, check
    **Alert Broadcast**. Service broadcasts are the most commonly missed path,
    because each service is configured separately and several services can
    broadcast into the same shared channel.
  </Step>

  <Step title="Check the default alerts channel and workflows">
    Review your Slack integration's default alerts channel, and search your
    [alert workflows](/workflows/alert-workflows) for steps that send Slack
    messages to the channel.
  </Step>
</Steps>

## Keep one owner per channel

Pick one mechanism as the single source of posts for each channel and remove
the channel from the others.

* **Escalation policy steps** give the finest control: different paths can
  notify the channel only for certain urgencies or time windows.
* **Broadcasts** are the simplest: every alert for the team or service lands in
  the channel, with no conditions.
* **Default alerts channel** is right when you intentionally run a single
  workspace-wide firehose of every alert. If you already own posts through a
  more specific mechanism (broadcasts or workflows) for a given channel,
  disable the default so those alerts don't post twice.
* **Workflows** are the most customizable, including message content.

<Note>
  If several services broadcast into one shared channel, disabling the
  broadcast on one service does not stop the others. Check every service that
  posts to that channel.
</Note>

## Related

* [Alerts overview](/alerts/alerts)
* [Escalation policies](/on-call/escalation-policies)
* [Alert workflows](/workflows/alert-workflows)