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

# Oh Dear alert integration

> Send uptime, performance, certificate, DNS, and scheduled task events from Oh Dear to Flashduty On-call through the team webhook.

Use the webhook in your Oh Dear team settings to send uptime, performance, broken links, mixed content, certificate, DNS, domain, sitemap, Lighthouse, AI check, application health, and scheduled task events to Flashduty On-call. Each check maps to one Flashduty alert: it triggers when the check fails and recovers when Oh Dear sends the matching recovery event.

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

  ***

  You can obtain an 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 **Oh Dear**, then 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 **Oh Dear** and enter an integration name
  3. Configure the default route and select a channel; after creation, add more rules under **Route** if needed
  4. Click **Save** and copy the generated **Push URL**
</div>

## Configure Oh Dear

***

The Oh Dear webhook is configured per team, and events from every monitor in the team go to the same URL.

<Steps>
  <Step title="Enter the webhook URL">
    1. Sign in to Oh Dear and open the team's **Notifications** page (team settings)
    2. On the **Global** tab, click **Add configuration** and choose **Webhooks** as the channel
    3. Paste the full Flashduty push URL into **Url**. The URL must include `integration_key`. A global configuration is used for every monitor in the team
    4. Oh Dear signs every request with the team's webhook signing secret, shown in the same dialog (the `OhDear-Signature` header). Flashduty authenticates with the `integration_key` in the URL and does not verify the signature
  </Step>

  <Step title="Save and verify">
    1. Click **Save**. In the configuration's **...** menu, choose **Send test notification**: Oh Dear posts `{"type":"test","uuid":"..."}`, Flashduty answers 200 and opens one separate Info alert titled "Oh Dear test notification". No recovery follows, so close it by hand. **Show webhook log** lists each delivery and the response status
    2. In Oh Dear, pause a test monitor or point it at an unreachable address, wait for the uptime check to fail, and confirm that Flashduty receives a Critical alert
    3. Restore the monitor's address and confirm that the alert recovers automatically

    Oh Dear treats only HTTP 200 as delivered. Any other status, including a 301 or 302 redirect, is resent, up to 3 attempts in total. Flashduty returns 200 for every event it recognizes and for every event it ignores.
  </Step>
</Steps>

## How events map to alerts

***

Oh Dear pushes every event, and you cannot filter event types on the Oh Dear side. Flashduty handles them as follows:

| Check | Trigger event | Recovery event |
| :- | :- | :- |
| Uptime | `httpUptimeCheckFailed`, `tcpUptimeCheckFailed`, `pingUptimeCheckFailed` | The matching `...UptimeCheckRecovered` |
| Performance threshold | `performanceThresholdExceeded` | `performanceThresholdRecovered` |
| Broken links | `brokenLinksFound` | `brokenLinksFixed` |
| Mixed content | `mixedContentFound` | `mixedContentFixed` |
| Certificate health | `certificateUnhealthy` | `certificateFixed` |
| DNS | `dnsIssuesFound` | `dnsIssuesFixed` |
| Application health | `applicationHealthProblemDetected` | `applicationHealthProblemFixed` |
| Sitemap | `sitemapIssuesFound` | `sitemapIssuesFixed` |
| DNS blocklist | `dnsBlocklistIssuesFound` | `dnsBlocklistIssuesFixed` |
| Domain | `domainIssuesFound` | `domainIssuesFixed` |
| Lighthouse | `lighthouseIssuesDetected` | `lighthouseIssuesFixed` |
| AI check | `aiCheckFailed` | `aiCheckSucceeded` |

These events have no recovery event. Each push creates a separate alert. Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit) (24 hours is a reasonable start), or close the alerts manually once handled: `certificateExpiresSoon`, `certificateHasChanged`, `dnsRecordsChanged`, `performanceDeltaExceeded`, `cronFailed` (a scheduled task reported an error), `cronNotExecutedOnTime` (a scheduled task did not report on time), `applicationHealthClientError`, and `applicationHealthResultsTooOld`.

Monitor added (`monitorAddedNotification`) and any event type Oh Dear adds later do not create alerts. Flashduty returns success for them.

<Warning>
  `applicationHealthProblemFixed` is sent per health item. When an application has several failing health items, the recovery of any one of them recovers the whole application health alert.
</Warning>

## Alert Key

***

* Checks with a recovery event: the Alert Key is computed from `run.check_id` (the ID of one kind of check under a monitor in Oh Dear). The trigger and recovery events of one check share an Alert Key, and different monitors, or different checks of the same monitor, never merge
* Events without a recovery event: the Alert Key is computed from the event's `uuid`. Oh Dear keeps the same `uuid` when it retries an event, so a retry does not create a duplicate alert, while each new event creates its own alert

Changes to the monitor name, URL, time, or run ID do not change the Alert Key. A push without `run.check_id` (checks with a recovery event) or without `uuid` (events without one) is rejected.

## Status and severity

***

Oh Dear events carry no severity, so Flashduty decides by event:

| Event | Status | Flashduty severity |
| :- | :- | :- |
| `...UptimeCheckFailed` (the site is unreachable) | Triggered | Critical |
| All other trigger events and events without a recovery event | Triggered | Warning |
| All recovery events | Recovered | - |

An uptime `...UptimeCheckRecovered` event with `run.result` set to `warning` means partial connectivity (the primary checker failed, the secondary succeeded, and the site still counts as online). Flashduty treats it as a recovery too.

## Labels

***

| Label | Source |
| :- | :- |
| `event` | The event name, without the `Notification` suffix and without the `http`/`tcp`/`ping` prefix of uptime events |
| `monitor_type` | The uptime monitor type: `http`, `tcp`, or `ping` |
| `monitor` / `monitor_id` | The monitor's label and ID |
| `resource` | The monitor's URL |
| `check_id` | The ID of the check that produced the event |
| `task` | The scheduled task name (scheduled task error events only) |
| `url` | Link to the matching report in Oh Dear |

## Troubleshooting

***

* **No alerts arrive**: check that `integration_key` in the URL is correct, and look at the request's response status in Oh Dear's webhook log
* **An alert does not recover**: check that Oh Dear has sent the matching recovery event. Certificate expiry, DNS record changes, and scheduled task events have none and must be closed manually
* **Testing**: Oh Dear's Send test notification only delivers a test request, which Flashduty answers with 200 and opens a separate Info alert to close by hand; to verify the alert path, use a real check failure as described above

For field details, see [Oh Dear webhooks](https://ohdear.app/docs/integrations/webhooks).