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 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 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, go to Integration Center → Alert Events
  2. Select Oh Dear and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  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

Add a webhook notification in Oh Dear

Where: Oh Dear › Team settings › Notifications › Global › Add configurationClick Save. A configuration on the Global tab applies to every monitor in the team. Oh Dear pushes every event type and you cannot filter on the Oh Dear side.Oh Dear signs every request with the team’s webhook signing secret, shown on the same page (the OhDear-Signature header). Flashduty authenticates with the integration_key in the URL and does not verify the signature.
2

Send a test notification in Oh Dear

Where: Oh Dear › Team settings › Notifications › Global › the webhook configuration’s … menu › Send test notificationOh 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. This step only proves that the network path and integration_key work; it does not exercise a real check’s alert and recovery.In the same … menu, choose Show webhook log to see each delivery’s request and response status. 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.
3

Verify with a real check failure

  1. 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 and the checklist’s “first event received” item turns green
  2. Restore the monitor’s address and confirm that the alert recovers automatically

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.