> ## 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.

# Notifications Overview

> How UptimeIO delivers alerts: destinations, events, delivery behaviour and message content

UptimeIO sends alerts through **notification destinations** that belong to your organization and are assigned directly to monitors. There is no separate alert-profile step.

```
Monitor  ->  Destinations  ->  Recipients
```

## How it works

<Steps>
  <Step title="Create destinations">
    Add one or more channels under **Destinations** in the sidebar: [email](/integrations/email), [Slack](/integrations/slack), [webhook](/integrations/webhooks), [Telegram](/integrations/telegram) or [Pushover](/integrations/pushover).
  </Step>

  <Step title="Choose events per destination">
    Each destination has its own event preferences, so email can receive everything while a pager channel receives only outages.
  </Step>

  <Step title="Assign destinations to monitors">
    Select the destinations in each monitor's **Notifications** section.
  </Step>

  <Step title="Receive alerts">
    When an event occurs, every verified destination assigned to the monitor with that event enabled is notified.
  </Step>
</Steps>

Step-by-step instructions are in [Setting Up Alerts](/essentials/setting-up-alerts).

## Events

<CardGroup cols={2}>
  <Card title="Monitor goes down" icon="circle-xmark">
    An incident opened after failures were confirmed from multiple probe locations.
  </Card>

  <Card title="Monitor recovers" icon="circle-check">
    The incident resolved after recovery was confirmed.
  </Card>

  <Card title="SSL certificate warnings" icon="lock">
    A certificate is 30, 15, 7 or 1 days from expiry (your selection per monitor). No incident is opened.
  </Card>

  <Card title="Domain expiry warnings" icon="globe">
    A domain registration is 30, 15, 7 or 1 days from expiry. No incident is opened.
  </Card>

  <Card title="Response time exceeds threshold" icon="clock">
    A slow-response incident opened.
  </Card>

  <Card title="Response time returns to normal" icon="gauge-high">
    The slow-response incident resolved.
  </Card>
</CardGroup>

<Note>
  DNS monitor failures are delivered as regular "Monitor goes down" and "Monitor recovers" events. There is no separate DNS event.
</Note>

All six events are enabled when you create a destination, and at least one must stay enabled.

## Event filtering

Each destination receives only the events toggled on in its own settings. For example, a destination with slow-response events switched off is still notified about outages, recoveries and expiry warnings, but never about slow responses.

## Delivery

* Notifications are sent as soon as the event occurs.
* Failed deliveries are retried automatically a limited number of times. Webhook requests time out after 10 seconds.
* For each incident you can see the delivery result of every notification on the incident page, under **Notification delivery**: **Sent**, **Failed** or **Pending**.

<Info>
  A destination assigned to a monitor receives one notification per event, even if it appears more than once in the monitor's settings.
</Info>

## Message content

Every notification identifies the monitor, what happened and why, and links back to the incident.

<Tabs>
  <Tab title="Email">
    The email subject names the event and monitor, for example `[UptimeIO] Monitor Down: API Server`. The body includes the monitor name and URL, the start time, the error details and a link to the incident.
  </Tab>

  <Tab title="Webhook">
    Webhooks receive a JSON envelope signed with your endpoint's secret:

    ```json theme={null}
    {
      "version": "1",
      "event": "monitor.down",
      "timestamp": 1757203200000,
      "monitor": {
        "id": "550e8400-e29b-41d4-a716-446655440000",
        "name": "Production API",
        "url": "https://api.example.com/health",
        "type": "HTTP"
      },
      "incident": {
        "id": "880e8400-e29b-41d4-a716-446655440000",
        "started_at": 1757203200000,
        "resolved_at": null
      },
      "subject": "Production API is down",
      "message": "Connection timeout after 10000ms"
    }
    ```

    See [Webhooks](/integrations/webhooks) for the field reference, headers and signature verification.
  </Tab>

  <Tab title="Slack, Telegram, Pushover">
    These channels receive a formatted message with the same information: the event, the monitor, the error and a link to the incident.
  </Tab>
</Tabs>

## Best practices

<AccordionGroup>
  <Accordion title="Name destinations clearly" icon="tag">
    Use names like `Production Slack` or `On-call Pushover` so they are easy to pick when configuring a monitor.
  </Accordion>

  <Accordion title="Match events to the channel" icon="sliders">
    * **Email**: all events, as an audit trail.
    * **Slack**: outages and recoveries.
    * **Pushover or Telegram**: outages only, for urgent attention.
    * **Webhook**: whatever your receiving system needs.
  </Accordion>

  <Accordion title="Test after every change" icon="vial">
    Use **Test** on the destination, then confirm end to end with a test monitor you can make fail.
  </Accordion>
</AccordionGroup>

## Team access

Organization owners and admins manage members and notification destinations. Paid plans do not charge per team member.

## Next steps

<CardGroup cols={2}>
  <Card title="Setting Up Alerts" icon="bell" href="/essentials/setting-up-alerts">
    Create and assign destinations
  </Card>

  <Card title="Email" icon="envelope" href="/integrations/email">
    Email destinations and verification
  </Card>

  <Card title="Slack" icon="slack" href="/integrations/slack">
    Post alerts to a channel
  </Card>

  <Card title="Webhooks" icon="webhook" href="/integrations/webhooks">
    Signed JSON to your own endpoint
  </Card>
</CardGroup>


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