Skip to main content
Use a Monitive (uptimemonitoring.com) monitor webhook to send down (monitor.down), flapping (monitor.flapping), and recovery (monitor.up) notifications to Flashduty On-call. Each monitor maps to one Flashduty alert: the alert triggers when the monitor goes down, flapping notifications update the same alert, and the alert recovers when the monitor is up again.

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 Channels and open a channel
  2. Select Settings → Integration data → Dedicated integrations, then click Add integration
  3. Select Monitive, 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 Monitive 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

In Monitive

A Monitive webhook recipient is created once at the account level and can be attached to many monitors. Attach it to every monitor you want to send to Flashduty.
1

Create a webhook recipient in Monitive

Where: Monitive console (app.uptimemonitoring.com) › Recipients › Create recipientClick Create recipient. The page shows Your recipient secret (the signing key) once and never again; Flashduty does not verify the signature, so you do not need to keep it.You can also create it through the API. When events is omitted, down, up, and flapping are all enabled:
2

Attach the recipient to your monitors

Open the settings of the monitor you want to connect in Monitive, check the recipient you just created, and click Save. Do this once for every monitor you want to send to Flashduty. When a monitor has no recipient, the console shows “No one is listening to this monitor”.When attaching through the API, PUT /api/v1/monitors/{monitorID}/recipients replaces the monitor’s complete recipient set instead of adding to it. GET the current set first, add the new recipient, and submit the whole set; otherwise the monitor’s other recipients are detached.
3

Take a monitor down in Monitive and confirm

Make the monitor really go down (for example, point it at a URL that returns 5xx). Go back to Flashduty: the integration shows a Latest event time and an active alert appears. Then restore the target and confirm the alert recovers. Monitive flips state only after it confirms from other regions, which usually takes one to a few minutes.POST /api/v1/recipients/{recipientID}/test sends a test delivery to the recipient, but it only proves connectivity: Monitive does not publish the test request body, and if it carries no monitor_id, Flashduty returns a parameter error, which does not mean the setup is wrong. Verify with a real outage.
The legacy PUT /api/v1/monitors/{monitorID}/webhook endpoint (one webhook slot per monitor) still works, but Monitive has marked it deprecated; use recipients for new setups. If the monitor already has a webhook, setting it again through the legacy endpoint replaces only the URL; the signing secret stays the same.
Every Monitive delivery carries an X-UptimeMonitoring-Signature (HMAC-SHA256) header. Flashduty does not verify it; the integration_key in the push URL is the credential, so keep the URL private. If a delivery fails (non-2xx or timeout), Monitive retries up to 5 times, after 1 minute, 5 minutes, 30 minutes, and 2 hours.

Payload

Monitive POSTs the following fields as application/json. Flashduty parses them directly; no template is needed: The alert title is the monitor name; if it is empty, the monitored URL is used, then Monitive monitor <monitor_id>.

Alert key

Flashduty uses monitor_id as the Alert Key. Down, flapping, and recovery notifications of one monitor carry the same monitor_id, so they land on the same alert; different monitors produce different alerts even when their names and URLs match. Renaming the monitor or changing its URL or reason does not change the Alert Key. delivery_id differs for every state change, so it is not part of the Alert Key. A request without monitor_id is rejected with a parameter error, because its recovery could not be matched to the original alert. A request whose event is none of the three values is acknowledged and ignored without creating an alert.

Status and severity

Monitive notifications carry no severity. A down monitor is an outage signal and maps to Critical; flapping maps to Warning.

FAQ

Monitive’s documentation says a flapping record ends once traffic stabilizes, but does not name the webhook event sent at that point. While a monitor is flapping, Monitive stops sending monitor.down and monitor.up for its further state changes, so no monitor.up closes the flapping alert during that time. A monitor.flapping that arrives after an earlier monitor.up opens a new Warning alert, because the previous alert is already closed. A later monitor.up closes the alert. If a monitor flaps and no monitor.up follows, the alert stays open, so turn on auto-close after timeout in the channel (for example 24 hours); see auto-close timeout.
No. A retried delivery carries the same monitor_id and merges into the same alert.
Webhooks are included in the free plan, with up to 50 monitors; one webhook recipient can be attached to many monitors.

Troubleshooting

  • Flashduty receives no alert: query GET /api/v1/webhook-deliveries?monitor_id=<id> in Monitive and check the delivery status and response code
  • Flashduty returns a parameter error: confirm the body is Monitive’s JSON and monitor_id is not empty
  • The alert does not recover: confirm the monitor.up delivery succeeded and the monitor’s webhook URL was not changed to another integration
For field details, see Monitive’s Webhooks documentation.