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

# OpenStatus alert integration

> Send OpenStatus monitor errors, degradations, and recoveries to Flashduty On-call through a Webhook notification channel.

Use an OpenStatus Webhook notification channel to send monitor alerts to Flashduty On-call. Each OpenStatus monitor maps to one Flashduty alert: it triggers when the monitor errors or degrades and recovers automatically when the monitor recovers.

<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 **OpenStatus** 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 **OpenStatus** 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 OpenStatus

***

<Steps>
  <Step title="Create a Webhook notification channel">
    1. Sign in to the OpenStatus dashboard and open **Notifications** in the sidebar
    2. Under **Create a new notifier**, click **Webhook**
    3. Enter `Flashduty` as the **Name**
    4. Paste the full Flashduty push URL into **Webhook URL**
    5. Leave **Request Headers** empty. OpenStatus always sends `application/json`
    6. Under **Monitors**, select the monitors that should alert, then click **Submit**. You can also attach the notifier later from a monitor's **Settings → Notifications**
  </Step>

  <Step title="Send a test">
    In the same form, click **Send Test**. The test message uses a fixed sample monitor (`monitor.id` `1`, name `test`, URL `http://openstat.us`). Flashduty returns success and creates no alert.
  </Step>

  <Step title="Verify the alert lifecycle">
    1. Create a monitor with the URL `https://openstat.us/500` (always returns 500) and attach the notification channel from the first step. OpenStatus checks the URL before saving and asks **Still save?** because it returns 500; click **Save**
    2. After at least half of the monitor's regions report an error, confirm that Flashduty receives a Critical alert
    3. Point the monitor back at a healthy URL, wait for the regions to recover, and confirm that the alert recovers
    4. Delete the test monitor when you are done
  </Step>
</Steps>

<Tip>
  OpenStatus sends an `error` notification only after at least half of the monitor's regions report an error, and recovery needs the same agreement, so alert timing depends on the monitor's check frequency. On the free plan the shortest check frequency is 10 minutes and you can create only one notification channel.
</Tip>

## Alert Key

***

Flashduty computes the Alert Key from `monitor.id` (the OpenStatus monitor ID). The `error`, `degraded`, and `recovered` notifications for a monitor carry the same `monitor.id`, so they land on the same alert: when the monitor goes from error to degraded, the alert is updated to Warning, and it closes when the monitor recovers.

Changes to the monitor name, URL, status code, latency, error message, or check time do not change the Alert Key. Flashduty rejects a request without `monitor.id` because it cannot be matched to a later recovery.

<Note>
  `monitor.id` is unique within one OpenStatus instance. If you use both OpenStatus cloud and a self-hosted instance, create a separate Flashduty integration for each instance so that monitor IDs from different instances do not collide.
</Note>

## Status and severity

***

| OpenStatus `status` | Flashduty handling | Severity |
| :- | :- | :- |
| `error` | Trigger or update the alert | Critical |
| `degraded` | Trigger or update the alert | Warning |
| `recovered` | Recover the alert | - |
| **Send Test** sample monitor | Return success, create no alert | - |

An empty or any other `status` is rejected so that a request whose state cannot be determined never lands in the wrong alert lifecycle.

## Alert content

***

* **Title**: the monitor name `monitor.name`, or `OpenStatus monitor <monitor.id>` when it is empty
* **Description**: `errorMessage`
* **Labels**: `check` (monitor name), `resource` (monitor URL `monitor.url`), `source` (always `openstatus`), `monitor_id`, `status`, `status_code`, `latency_ms`

## Troubleshooting

***

* **Send Test fails**: make sure **Webhook URL** is the full push URL and includes `integration_key`
* **Flashduty returns a parameter error**: make sure the request has `monitor.id` and `status`. This integration accepts only the JSON format of the OpenStatus Webhook channel
* **No alert arrives**: make sure the monitor is selected under the channel's **Monitors** and that it has errored in at least half of its regions
* **The alert does not recover**: make sure the monitor has recovered in at least half of its regions and is still attached to the channel when it recovers

For field definitions, see the [OpenStatus Notification Reference](https://www.openstatus.dev/docs/reference/notification).