Skip to main content
Use the Uptime.com Custom Postback URL (Webhook) to send check alerts to Flashduty On-call. Each Uptime.com check maps to one Flashduty alert: it triggers when the check goes down and recovers automatically when the check is back up.

​
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 an integration
  3. Select Uptime.com and click Save
  4. Open the new integration card and copy the Push URL

​
Use a shared integration

  1. In the Flashduty console, select Integration Center → Alert Events
  2. Select Uptime.com and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routes after creation
  4. Click Save and copy the generated Push URL

​
Configure Uptime.com

1

Create a Custom Postback URL integration

  1. Sign in to Uptime.com, go to Notifications → Integrations, and click New Profile
  2. Set Provider Type to Custom Postback URL (Webhook)
  3. Name the profile Flashduty
  4. Paste the full Flashduty push URL into URL
  5. Leave Custom HTTP Headers empty. Uptime.com always sends application/json
  6. In Assign to Contacts, select the contact that should receive the alerts, then click Save
2

Assign the contact to checks

Uptime.com delivers alerts through contacts: only checks that have this contact assigned push to Flashduty.
  • If the contact you selected in the previous step is already assigned to the checks you want to alert on, skip this step
  • For a dedicated contact, go to Notifications → Contacts, create a contact, and select Flashduty under Integrations
  • Edit each check that should alert, add the contact under Contacts, and save
3

Send a test and verify the lifecycle

  1. Under Notifications → Integrations, find Flashduty in the Active list and click More Actions → Test. The test message has event set to test. Flashduty returns success and creates no alert
  2. Make a check with the contact assigned actually fail, for example by temporarily misspelling the domain of an HTTP(S) check, and confirm that Flashduty receives an active alert
  3. Restore the check configuration, wait for the check to recover, and confirm that the alert recovers
When a check fails, Uptime.com uses the check’s Sensitivity (how many probe locations must fail at once) to decide whether to raise an alert, so the alert arrives after several locations confirm the failure. Downtime that starts inside a maintenance window sends no alert.

​
Alert Key

Flashduty computes the Alert Key from data.service.id, the Uptime.com check ID. The alert_raised and alert_cleared messages of a check carry the same data.service.id, so they land on the same alert. Repeat notifications during an ongoing outage merge into that alert as well. data.alert.id identifies a detection record from one probe location and changes on recovery, so it is not part of the Alert Key. Changes to the check name, tags, state, output, timestamps, or failing locations do not change the Alert Key. A request without data.service.id is rejected, because its recovery could not be matched.

​
Status and severity

An empty or any other event is rejected so that an ambiguous request cannot enter the wrong alert lifecycle. Severity comes from data.alert.state: Recovery events keep the original alert severity.

​
Alert content

  • Title: the check’s display_name, or name when it is empty
  • Description: data.alert.output, or data.alert.short_output when it is empty
  • Labels: check (check name), resource (check address msp_address), source (always uptime-com), service_id, check_type (monitoring_service_type), device, tags (comma-separated), alert_state, is_up, locations (comma-separated), num_locations_down, alert_details, real_time_analysis
The push URL and custom headers in data.integration are never written to labels.

​
Troubleshooting

  • The integration shows an error or Uptime.com fails to deliver: confirm that the URL is the full push URL and includes integration_key
  • Flashduty returns a parameter error: confirm that the request contains event and data.service.id. This integration accepts only the Custom Postback URL JSON format
  • No alert arrives: confirm that the check’s Contacts include the contact assigned to the Flashduty integration
  • The alert does not recover: confirm that the check has actually recovered and still had the contact assigned when it recovered
For field definitions, see Configuring Custom Postback URL | Webhooks.