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

# Setting Up Alerts

> Create notification destinations, choose which events each one receives, and assign them to monitors

Alerts are delivered through **notification destinations**. A destination is one channel (an email address, a Slack channel, a webhook URL, a Telegram chat or a Pushover account) with its own list of events. You assign destinations to monitors, and a destination can be shared by many monitors.

```
Monitor  ->  Destinations  ->  You
```

## Supported destination types

| Type | What you provide | Guide |
| - | - | - |
| **Email** | An email address (verified before use) | [Email](/integrations/email) |
| **Slack** | A Slack workspace and channel (OAuth), or an Incoming Webhook URL | [Slack](/integrations/slack) |
| **Webhook** | An HTTPS URL, method (`POST` or `PUT`), optional headers | [Webhooks](/integrations/webhooks) |
| **Telegram** | A Telegram chat, connected by messaging the UptimeIO bot | [Telegram](/integrations/telegram) |
| **Pushover** | Your Pushover user key (and optionally an application token) | [Pushover](/integrations/pushover) |

Telegram and Pushover destinations can only be created from the dashboard; an API key cannot create them.

## Create a destination

<Steps>
  <Step title="Open Destinations">
    Click **Destinations** in the sidebar, then **Add Destination**.
  </Step>

  <Step title="Choose the type and configure it">
    Enter a descriptive name (for example `Production Slack`) and the type-specific details from the guide above.
  </Step>

  <Step title="Choose the events">
    Toggle the events this destination should receive (see the table below). At least one event must be enabled. All events are enabled by default.
  </Step>

  <Step title="Verify and test">
    Email destinations must be verified before they receive alerts. Use **Test** on any destination to send a test notification.
  </Step>
</Steps>

## Events

Event preferences are set separately on each destination. A destination receives only the events enabled on it.

| Event (dashboard label) | Preference key | Sent when |
| - | - | - |
| Monitor goes down | `on_failure` | An incident opens after failures are confirmed from multiple locations. |
| Monitor recovers | `on_recovery` | The incident resolves. |
| SSL certificate warnings | `on_ssl_expiry` | A certificate is nearing expiry (30, 15, 7 or 1 days). |
| Domain expiry warnings | `on_domain_expiry` | A domain registration is nearing expiry (30, 15, 7 or 1 days). |
| Response time exceeds threshold | `on_slow_response` | A slow-response incident opens. |
| Response time returns to normal | `on_slow_response_resolved` | The slow-response incident resolves. |

DNS monitor failures are delivered as regular "Monitor goes down" and "Monitor recovers" events.

## Assign destinations to a monitor

<Steps>
  <Step title="Open the monitor's settings">
    Create a new monitor, or edit an existing one.
  </Step>

  <Step title="Select destinations">
    In the **Notifications** section, tick the destinations that should receive this monitor's alerts.
  </Step>

  <Step title="Save">
    Save the monitor. Through the API, send the destination IDs in `notification_target_ids` when you [create](/api-reference/monitors/create) or [update](/api-reference/monitors/update) the monitor.
  </Step>
</Steps>

<Warning>
  A monitor with no destination assigned raises incidents but notifies nobody. The dashboard shows a reminder banner when you have no destinations.
</Warning>

## Certificate and domain expiry warnings

These two warnings are sent to your destinations **without opening an incident**.

| Warning | Thresholds | Default | Notes |
| - | - | - | - |
| SSL certificate expiry | 30, 15, 7, 1 days before expiry | 7 and 1 days | Choose which thresholds you want per monitor. An expired or invalid certificate opens an incident instead; see [Understanding Incidents](/essentials/understanding-incidents#ssl-certificate-problems). |
| Domain expiry | 30, 15, 7, 1 days before expiry | All four | Available on HTTP, keyword and DNS monitors whose target is a publicly registered domain. IP addresses, `localhost` and internal names are rejected. Registration data is fetched by RDAP lookup and warnings are evaluated hourly. Some country-code domains do not publish an expiry date; those show "not published" and never warn. |

Both warnings are controlled by the `on_ssl_expiry` and `on_domain_expiry` events on each destination.

## Example setups

<Tabs>
  <Tab title="Solo developer">
    * Email `me@example.com`, all events.
  </Tab>

  <Tab title="Small team">
    * Email `team@example.com`, all events (audit trail).
    * Slack `#monitoring`, events: goes down, recovers.
  </Tab>

  <Tab title="Critical production">
    * Email `ops@example.com`, all events.
    * Slack `#production`, events: goes down, recovers.
    * Pushover for on-call, events: goes down only.
    * Webhook to your incident tooling, all events.
  </Tab>
</Tabs>

## Test your alerts

<Steps>
  <Step title="Test the destination">
    Use **Test** on the destination. Email destinations are limited to 3 test emails per day per destination.
  </Step>

  <Step title="Test end to end">
    Point a test monitor at a URL you can make fail, or set its expected status code to one the page does not return, and confirm that the alert arrives. Then restore the settings.
  </Step>

  <Step title="Check delivery">
    Open an incident and look at **Notification delivery** to see whether each notification was sent, failed or is pending.
  </Step>
</Steps>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Not receiving email alerts">
    1. The destination is verified (a pending destination receives nothing).
    2. Check spam or junk.
    3. The destination is assigned to the monitor.
    4. The relevant event is enabled on the destination.
  </Accordion>

  <Accordion title="Slack messages not appearing">
    1. Re-run the connection from the destination if Slack reports an authorisation error.
    2. For private channels, invite the UptimeIO app to the channel.
    3. The relevant event is enabled on the destination.
  </Accordion>

  <Accordion title="Receiving too many notifications">
    1. Turn off events you do not act on, such as "Response time returns to normal".
    2. Use separate destinations for different urgency.
    3. Raise the interval on non-critical monitors.
  </Accordion>
</AccordionGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Notifications Overview" icon="bell" href="/notifications/overview">
    Delivery, retries and message content
  </Card>

  <Card title="Understanding Incidents" icon="triangle-exclamation" href="/essentials/understanding-incidents">
    When alerts fire
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.