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

# UptimeObserver alert integration

> Send UptimeObserver incident and resolution webhooks to Flashduty On-call.

Use UptimeObserver webhooks to send monitor incidents to Flashduty On-call. Each UptimeObserver incident maps to one Flashduty alert: the Incident webhook triggers it and the Resolution webhook recovers the same alert.

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

  ***

  Create either a dedicated or shared **UptimeObserver** alert integration and copy its complete Push URL.
</div>

## Configure UptimeObserver

***

UptimeObserver has no fixed webhook payload; the body comes from the template you enter. Flashduty parses only the two templates below, so create two webhooks: one for incidents and one for resolutions.

<Steps>
  <Step title="Create the Incident webhook">
    1. In the UptimeObserver console, open the Integrations page and add a **Webhook** integration
    2. Enter a name, then set Method to **POST**, HTTP Body Encoding to **application/json**, and Authentication to **None** (none of these is selected by default). The webhook form has no trigger setting; the trigger is chosen when you attach the webhook to a monitor
    3. Paste the complete Flashduty integration Push URL into the URL field
    4. Paste this JSON as the body template:

    ```json theme={null}
    {
      "event_type": "trigger",
      "incident_url": "__INCIDENT_URL__",
      "incident_id": __INCIDENT_ID__,
      "incident_status": "__INCIDENT_STATUS__",
      "monitor_id": __MONITOR_ID__,
      "monitor_name": "__MONITOR_FRIENDLY_NAME__",
      "monitor_url": "__MONITOR_URL__",
      "root_cause": "__INCIDENT_ROOT_CAUSE__"
    }
    ```
  </Step>

  <Step title="Create the Resolution webhook">
    Add a second webhook with the same URL and the same options, and paste this body template:

    ```json theme={null}
    {
      "event_type": "resolved",
      "incident_url": "__INCIDENT_URL__",
      "incident_id": __INCIDENT_ID__,
      "incident_status": "__INCIDENT_STATUS__",
      "monitor_id": __MONITOR_ID__,
      "monitor_name": "__MONITOR_FRIENDLY_NAME__",
      "monitor_url": "__MONITOR_URL__"
    }
    ```

    <Warning>
      Keep `event_type` as `trigger` and `resolved` respectively, and keep `incident_id` unquoted in both templates. Flashduty rejects a request without `incident_id` or `event_type` because it cannot reliably match an incident to its recovery.
    </Warning>
  </Step>

  <Step title="Attach the webhooks to your monitors">
    Open each monitor you want to route and click **Add Alert**. Set **Alert Type** to **Webhook** and select the webhook. For **Event**, pick **Monitor Down** for the Incident webhook and **Monitor Up** for the Resolution webhook, then click **Save changes**. Add both alerts to every monitor.
  </Step>

  <Step title="Verify the lifecycle">
    Make the monitored endpoint genuinely unreachable and confirm Flashduty shows an active alert. Restore it and confirm the same alert recovers. UptimeObserver's test send only verifies connectivity; it does not prove that an incident and its recovery are correlated.
  </Step>
</Steps>

## Alert Key

***

Flashduty uses `incident_id` (`__INCIDENT_ID__`) as the Alert Key. UptimeObserver documents it as the numeric incident identifier and uses it in both its incident and resolution example templates. The documentation does not state outright that the two webhooks carry the same value for one incident, so this is inferred; verify it with a real outage when you first set up the integration.

`monitor_id` is stored only as a label. Changes to the monitor name, root cause, or `incident_status` do not change the Alert Key. The next outage of the same monitor is a new incident and therefore a new alert.

## Status and severity

***

| `event_type` | Flashduty status or severity |
| :- | :- |
| `trigger` | Critical (the monitor is down) |
| `resolved` | Recovered; original severity Critical |

An empty or unknown `event_type` is rejected. An empty object `{}` returns 200 and creates no alert.

## Troubleshooting

***

* **UptimeObserver reports a non-2xx response**: confirm the URL is complete and includes `integration_key`
* **Flashduty returns an invalid-parameter error**: confirm the body is valid JSON. UptimeObserver substitutes `__INCIDENT_ROOT_CAUSE__` and the monitor name as raw text, so a double quote in either can break the JSON; remove the `root_cause` field or avoid quotes in monitor names
* **The alert never recovers**: confirm the Resolution webhook exists, its `event_type` is `resolved`, and it is attached to the same monitor
* **The test succeeds but real alerts do not arrive**: check that the monitor actually opened an incident and that both webhooks are attached to it

See [UptimeObserver webhooks](https://support.uptimeobserver.com/integrations/webhooks/) for the variable reference.