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

# Uptime.com alert integration

> Send Uptime.com check downtime and recovery to Flashduty On-call through the Custom Postback URL (Webhook).

Use the Uptime.com Custom Postback URL (Webhook) to send check alerts to Flashduty On-call. Each Uptime.com check maps to one Flashduty alert: it triggers when the check goes down and recovers automatically when the check is back up.

<div className="hide">
  ## In Flashduty On-call

  ***

  You can get the integration push URL in either of the following ways.

  ### Use a dedicated integration

  1. In the Flashduty console, select **Channel** and open a channel
  2. Select **Configuration** → **Integrations** → **Private integration**, then click **Add an integration**
  3. Select **Uptime.com** and click **Save**
  4. Open the new integration card and copy the **Push URL**

  ### Use a shared integration

  1. In the Flashduty console, select **Integration Center → Alert Events**
  2. Select **Uptime.com** and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under **Routes** after creation
  4. Click **Save** and copy the generated **Push URL**
</div>

## Configure Uptime.com

***

<Steps>
  <Step title="Create a Custom Postback URL integration">
    1. Sign in to Uptime.com, go to **Notifications → Integrations**, and click **New Profile**
    2. Set **Provider Type** to **Custom Postback URL (Webhook)**
    3. Name the profile `Flashduty`
    4. Paste the full Flashduty push URL into **URL**
    5. Leave **Custom HTTP Headers** empty. Uptime.com always sends `application/json`
    6. In **Assign to Contacts**, select the contact that should receive the alerts, then click **Save**
  </Step>

  <Step title="Assign the contact to checks">
    Uptime.com delivers alerts through contacts: only checks that have this contact assigned push to Flashduty.

    * If the contact you selected in the previous step is already assigned to the checks you want to alert on, skip this step
    * For a dedicated contact, go to **Notifications → Contacts**, create a contact, and select `Flashduty` under **Integrations**
    * Edit each check that should alert, add the contact under **Contacts**, and save
  </Step>

  <Step title="Send a test and verify the lifecycle">
    1. Under **Notifications → Integrations**, find `Flashduty` in the **Active** list and click **More Actions → Test**. The test message has `event` set to `test`. Flashduty returns success and creates no alert
    2. Make a check with the contact assigned actually fail, for example by temporarily misspelling the domain of an HTTP(S) check, and confirm that Flashduty receives an active alert
    3. Restore the check configuration, wait for the check to recover, and confirm that the alert recovers
  </Step>
</Steps>

<Tip>
  When a check fails, Uptime.com uses the check's **Sensitivity** (how many probe locations must fail at once) to decide whether to raise an alert, so the alert arrives after several locations confirm the failure. Downtime that starts inside a maintenance window sends no alert.
</Tip>

## Alert Key

***

Flashduty computes the Alert Key from `data.service.id`, the Uptime.com check ID. The `alert_raised` and `alert_cleared` messages of a check carry the same `data.service.id`, so they land on the same alert. Repeat notifications during an ongoing outage merge into that alert as well.

`data.alert.id` identifies a detection record from one probe location and changes on recovery, so it is not part of the Alert Key. Changes to the check name, tags, state, output, timestamps, or failing locations do not change the Alert Key. A request without `data.service.id` is rejected, because its recovery could not be matched.

## Status and severity

***

| Uptime.com `event` | Flashduty handling                   |
| :----------------- | :----------------------------------- |
| `alert_raised`     | Triggers or updates the alert        |
| `alert_cleared`    | Recovers the alert                   |
| `test`             | Returns success and creates no alert |

An empty or any other `event` is rejected so that an ambiguous request cannot enter the wrong alert lifecycle.

Severity comes from `data.alert.state`:

| Uptime.com `data.alert.state` | Flashduty severity |
| :---------------------------- | :----------------- |
| `WARNING`                     | Warning            |
| `CRITICAL`                    | Critical           |
| Any other value or empty      | Critical           |

Recovery events keep the original alert severity.

## Alert content

***

* **Title**: the check's `display_name`, or `name` when it is empty
* **Description**: `data.alert.output`, or `data.alert.short_output` when it is empty
* **Labels**: `check` (check name), `resource` (check address `msp_address`), `source` (always `uptime-com`), `service_id`, `check_type` (`monitoring_service_type`), `device`, `tags` (comma-separated), `alert_state`, `is_up`, `locations` (comma-separated), `num_locations_down`, `alert_details`, `real_time_analysis`

The push URL and custom headers in `data.integration` are never written to labels.

## Troubleshooting

***

* **The integration shows an error or Uptime.com fails to deliver**: confirm that the URL is the full push URL and includes `integration_key`
* **Flashduty returns a parameter error**: confirm that the request contains `event` and `data.service.id`. This integration accepts only the Custom Postback URL JSON format
* **No alert arrives**: confirm that the check's **Contacts** include the contact assigned to the `Flashduty` integration
* **The alert does not recover**: confirm that the check has actually recovered and still had the contact assigned when it recovered

For field definitions, see [Configuring Custom Postback URL | Webhooks](https://support.uptime.com/hc/en-us/articles/115002560845-Configuring-Custom-Postback-URL-Webhooks).