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

# Notifications

> Configure organization-wide notification destinations and defaults

Use **Settings > Notifications** to decide where Cotool sends important operational updates for your organization. This page controls shared notification defaults for alert escalations, log-ingest health, agent failures, and, when enabled in your workspace, detection tuning.

Notification destinations are shared across your organization. A destination you create here can be reused in other notification settings and anywhere else Cotool asks for an output destination.

## Open the page

Go to [Settings > Notifications](https://app.cotool.ai/platform/notifications).

The page is organized into tabs. Each tab lets you enable or disable a notification type and choose one or more destinations.

## Manage destinations

Each tab uses the same destination picker:

1. Turn the notification type on.
2. Open **Destinations**.
3. Select one or more existing destinations.
4. Or choose **New Destination** to create one while staying on the page.
5. Save your changes.

Depending on which integrations are connected in your workspace, destinations can include Slack, Microsoft Teams, webhooks, PagerDuty, Linear, or Tines.

<Note>
  Destination availability depends on your connected integrations. For
  example, Slack destinations require the Slack integration to be connected,
  and PagerDuty destinations require PagerDuty to be connected.
</Note>

## Alerts tab

The **Alerts** tab controls notifications for escalated alerts.

When enabled, Cotool sends a notification each time an alert moves into **Escalated** status, whether that escalation came from a response agent or a person.

You can also set a **Minimum severity** so lower-severity escalations do not notify.

Use this tab when you want an on-call channel, incident system, or downstream workflow to hear about alerts that need higher-attention review.

Related guide: [Alert Routing](/alerts/routing)

## Log ingest tab

The **Log ingest** tab controls notifications for managed log-ingest health changes.

You can choose which stream states notify:

* **No access** - the provider is refusing access and you need to fix the source-side configuration or credentials
* **Degraded** - logs are missing, late, or not catching up as expected
* **Stalled** - the stream is not making progress within its freshness window
* **Failing** - a run exhausted its retries and will not recover on its own

Backfilling, recovering, and waiting streams never notify because they are expected or self-healing states.

Use this tab when you want the right team to know when a source stops delivering trustworthy data.

Related guide: [Monitor Log Ingestion](/log-ingest/monitoring)

## Agent failures tab

The **Agent failures** tab sets the default destinations for:

* terminal run failures
* failed acceptance criteria
* critical issues detected during evaluation

These are organization defaults. Individual agents can still override their own failure-notification settings.

Use this tab to make sure broken or off-track agent runs reach the people or systems that need to investigate them.

Related guide: [Acceptance Criteria](/improving-agents/acceptance-criteria)

## Detection tuning tab

If detection autotuning is enabled in your workspace, the **Detection tuning** tab controls notifications when Cotool automatically applies a tuning proposal and publishes a new detection version.

This tab only covers **auto-applied** tuning changes. Review-only proposals still wait for a person to approve or reject them.

Use this tab when detection owners want visibility into automatic noise-reduction changes without watching the detections workspace continuously.

Related guide: [Operate and Tune Detections](/detections-platform/operations#review-tuning-proposals)

## Best practices

* Send different notification types to different destinations when different teams own the response.
* Start with a small set of destinations to avoid duplicate noise across channels.
* For log-ingest health, notify only on the states your team actively responds to.
* Review shared destinations before deleting or repointing them, since other notification flows may reuse them.

## Related documentation

<CardGroup cols={2}>
  <Card title="Monitor log ingestion" href="/log-ingest/monitoring" icon="heart-pulse">
    Understand the health states used by log-ingest notifications.
  </Card>

  <Card title="Alert routing" href="/alerts/routing" icon="route">
    Learn how alerts are created, assigned, and escalated.
  </Card>

  <Card title="Acceptance criteria" href="/improving-agents/acceptance-criteria" icon="list-check">
    Configure per-agent evaluation checks and failure handling.
  </Card>

  <Card title="Operate and tune detections" href="/detections-platform/operations" icon="sliders">
    Review detection schedules, hits, and tuning proposals.
  </Card>
</CardGroup>
