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 in UptimeObserver

Where: UptimeObserver › Integrations › WebhooksThe webhook form has no trigger setting; the trigger is chosen when you attach the webhook to a monitor. Paste this JSON into HTTP Body and click Save Webhook:
2

Create the Resolution webhook in UptimeObserver

Where: UptimeObserver › Integrations › WebhooksAdd a second webhook with all other fields the same as the previous step (URL is again {integration_url}), named for example Flashduty Resolution, and paste this HTTP Body:
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 in UptimeObserver

Where: UptimeObserver › the monitor’s edit page › Add Alert (the vendor’s webhook guide does not list where this entry sits; follow your UI)For each monitor you want to route, add two alerts and set Alert Type to Webhook on both:Then click Save changes.
4

Verify the lifecycle

Where: UptimeObserver › Integrations › Webhooks (after saving a webhook, click its test button)The test button only verifies connectivity: its sample incident is acknowledged and ignored by Flashduty, so no alert is created, and it does not prove that an incident and its recovery are correlated. Make the monitored endpoint genuinely unreachable and confirm Flashduty shows an active alert. Restore it and confirm the same alert recovers.

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. In a real outage, the incident and resolution webhooks carry the same incident_id, so the recovery closes the matching alert. 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.