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

# Bleemeo alert integration

> Send Bleemeo metric status changes, both alerts and recoveries, to Flashduty On-call through a webhook integration.

Use a Bleemeo webhook integration to send metric status changes to Flashduty On-call. A metric entering Warning, Critical, or Unknown status triggers an alert, and the metric returning to OK closes the same alert.

<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, go to **Channels** and open a channel
  2. Select **Configuration** → **Integrations** → **Private integration**, then click **Add an integration**
  3. Select **Bleemeo** and click **Save**
  4. Open the new integration card and copy the **push URL**

  ### Use a shared integration

  1. In the Flashduty console, go to **Integration Center → Alert Events**
  2. Select **Bleemeo** 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 Bleemeo

***

<Steps>
  <Step title="Add a webhook notification target">
    1. Sign in to Bleemeo and go to **Notifications → Notification Targets**, then click **+**
    2. Select **webhook** as the type, enter a display name, and paste the full Flashduty push URL as the **Target** (Bleemeo requires the endpoint to be reachable from its servers and to return a 2xx status code)
    3. Under **Advanced settings**, **Notify on** lists OK, Warning and Critical; keep OK selected so recoveries are sent
    4. Leave **Send test notification after saving** selected if you want a test, then click **Save**. The test opens a separate Info alert in Flashduty; close it manually
  </Step>

  <Step title="Select the target in a notification rule">
    Go to **Notifications → Notification Rules**, click **+**, keep the scope and problem, choose **Notification Targets** as the target type, and select the new target. Bleemeo then sends a notification to the URL when a metric changes status, and again when it recovers.
  </Step>

  <Step title="Verify the lifecycle">
    Push a metric past its threshold (for example, temporarily lower a CPU usage threshold) and confirm an active alert appears in Flashduty. Restore the threshold and confirm the same alert recovers.
  </Step>
</Steps>

## Payload

***

Bleemeo POSTs a JSON notification. Flashduty parses it directly, with no template to configure:

| Field | Meaning | In Flashduty |
| :- | :- | :- |
| `metric` | Metric ID | Alert Key, label `metric_id` |
| `status` | Status: `0` OK, `1` Warning, `2` Critical, `3` Unknown | Alert status or severity |
| `title` | Summary with the host and metric | Alert title, label `check` |
| `text` | Additional detail such as the current value | Alert description |
| `agent` | ID of the Agent on the host | Labels `agent_id`, `resource` |
| `status_text` | Status text | Label `status_text` |

## Alert Key

***

Flashduty uses `metric` as the Alert Key. The alert and recovery notifications of one metric carry the same `metric`, so they land on the same alert, while different metrics produce different alerts. The top-level `id` is not part of the Alert Key, and changes to the title, value, or time do not change it.

If `metric` is missing, Flashduty returns a parameter error, because a recovery cannot be reliably matched to its alert.

## Status and severity

***

| Bleemeo `status` | Flashduty status or severity |
| :- | :- |
| `0` (OK) | Recovery |
| `1` (Warning) | Warning |
| `2` (Critical) | Critical |
| `3` (Unknown) | Warning |

A request with an empty or any other `status` is rejected, so a request whose state is unclear never enters the wrong alert lifecycle.

## FAQ

***

<AccordionGroup>
  <Accordion title="Which Bleemeo plan includes webhooks?">
    Refer to Bleemeo's current plan description. Webhooks may require a higher tier, and the trial period usually includes them.
  </Accordion>

  <Accordion title="Do repeated notifications create several alerts?">
    No. Bleemeo may retry failed deliveries, and notifications for one metric carry the same `metric`, so they merge into one alert.
  </Accordion>

  <Accordion title="Does an Unknown status recover the alert?">
    No. `3` (Unknown) is handled as Warning, and only `0` (OK) closes the alert.
  </Accordion>
</AccordionGroup>

## Troubleshooting

***

* **The test notification opens an Info alert**: the test sent after saving a target has no metric and is recognised by its fixed body (status `10`, title `Test`); it opens its own Info alert that never recovers, so close it manually

* **Bleemeo reports a failed delivery**: confirm the webhook URL is the full push URL and includes `integration_key`

* **Flashduty returns a parameter error**: confirm the request is a Bleemeo JSON notification with a non-empty `metric` and a `status` from 0 to 3

* **The alert does not recover**: confirm the recovery is sent through the same webhook integration; the recovery and the alert must carry the same `metric`

For field details, see the Bleemeo documentation: [Webhook](https://docs.bleemeo.com/alerting/integrations/webhook/).