Skip to main content
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.

​
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

​
Configure Oh Dear

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

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
2

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.

​
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: These events have no recovery event. Each push creates a separate alert. Turn on the channel’s auto-resolve timeout (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.
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.

​
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: 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

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