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

​
In Flashduty On-call

Create either a dedicated or shared UptimeObserver alert integration and copy its complete Push URL.

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

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

Create the Resolution webhook

Add a second webhook with the same URL and the same options, and paste this body template:
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.
3

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

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.

​
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

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 for the variable reference.