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

# Robotalp alert integration

> Send Robotalp monitor downtimes and recoveries to Flashduty On-call through its Custom Webhook.

Robotalp is an uptime monitoring service. When a monitor goes down or recovers, it can post a JSON body to a Custom Webhook URL. Set that URL to a Flashduty Push URL and each downtime maps to one Flashduty alert: going down triggers a Critical alert, and the recovery of the same downtime recovers it.

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

  ***

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

  ### Use a dedicated integration

  1. In the Flashduty console, select **Channels** and open a channel
  2. Select **Settings** → **Integrations** → **Dedicated integrations**, then click **Add an integration**
  3. Select **Robotalp** and click **Save**
  4. Open the generated integration card and copy the **Push URL**

  ### Use a shared integration

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

## Configure Robotalp

***

<Steps>
  <Step title="Add a Custom Webhook integration">
    1. Sign in to Robotalp, click the avatar in the top-right corner to open the account menu, and select **Integrations**
    2. Click **Add Integration** and select **Custom Webhook**
    3. Enter a name and set the URL to the complete Flashduty Push URL, including `integration_key`
    4. Save. No custom headers are needed

    <Warning>
      The JSON you enter in **Custom payload** is merged into every request body. Do not use the field names `incident_id`, `status`, or `monitor_id` there; they would overwrite Robotalp's own fields and the recovery could no longer be matched to its alert.
    </Warning>
  </Step>

  <Step title="Enable the webhook on each monitor">
    1. Edit the robot you want to watch (in the create or edit dialog) and open its **Alerts** tab
    2. Under **Notification Preferences**, turn on the webhook you just created
    3. If a notification frequency option is offered, **only once until resolved** is recommended (one notification when the monitor goes down, one when it recovers)

    The webhook must be enabled per monitor; creating the integration alone sends nothing.
  </Step>

  <Step title="Verify">
    1. Click **Test Connection** in the Add Integration or edit form. Flashduty creates an Info alert titled `Robotalp test notification`. It never recovers, so close it by hand after checking
    2. Temporarily change the monitor's address to one that returns an error (for example HTTP 503) and wait for the next check; a Critical alert appears in Flashduty
    3. Change the address back and wait for the next check; the alert recovers

    The check interval is set on the monitor; with a 1-minute interval, the down and recovery notifications usually arrive within about a minute.
  </Step>
</Steps>

## Alert Key

***

Flashduty uses `incident_id` from the request body as the Alert Key. Robotalp sends the same `incident_id` on the down notification and the recovery notification of one downtime. We verified this on a real Robotalp account: a monitor went down and then recovered, and both deliveries carried the same `incident_id`.

* Changes to the monitor name, address, error message, or downtime duration do not change the Alert Key
* Two separate downtimes of the same monitor have different `incident_id` values and become two alerts
* Requests without `incident_id` are rejected, because their recovery could not be matched reliably

## Status and severity

***

The Robotalp request body has no severity field, only `status`.

| Robotalp `status` | Flashduty status or severity |
| :- | :- |
| `down` | Critical (a website outage is a failure signal) |
| `up` | Recovery |

Any other value is rejected. A recovery carries `resolved_at` and `downtime_seconds`; Flashduty stores them as labels together with the failure reason `result_message`.

## Troubleshooting

***

* **Flashduty receives nothing**: confirm the webhook is enabled under the monitor's **Notification Preferences** and that the Push URL is complete, including `integration_key`
* **The alert does not recover**: confirm **Custom payload** does not override `incident_id` or `status`. If the monitor is paused or deleted, Robotalp sends no recovery, so close the alert by hand; you can also turn on auto-close in the channel as a fallback
* **The test alert stays open**: the Test Connection delivery never recovers; close it by hand

For more details, see Robotalp's [Webhook integration](https://docs.robotalp.com/guides/integrations/webhook) guide.


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