Skip to main content
Dotcom-Monitor is a cloud service for website, API and server monitoring. Its HTTP Webhook address type sends a request, built from an alert template you write, to a URL when a device changes state. Dotcom-Monitor has no fixed webhook body, so this integration requires you to paste the JSON template below into your alert template, and Flashduty parses the fields of that template. Each monitored device maps to one Flashduty alert: it opens when the device fails and closes automatically when the recovery notification (ALL CLEAR) arrives.

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 Dotcom-Monitor and 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 Dotcom-Monitor 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 Dotcom-Monitor

1

Create an alert template in Dotcom-Monitor

Where: Dotcom-Monitor › Manage › Custom Alert Templates › New TemplateCreate a JSON alert template (see Alert Template: Setup and Configuration) and paste the following. The field names must stay exactly as shown:
The variables come from the Dotcom-Monitor Dynamic Variables Reference. Recovery notifications carry no error information, so the error-related variables use the null-safe ?. form.
2

Add an HTTP Webhook address

Where: Dotcom-Monitor › Alert Group › New Address › HTTP WebhookAdd an address to an Alert Group in Dotcom-Monitor (the entry point for alert groups is named differently across versions, so find the alert group settings in your console) and fill in:Save, and assign the alert group to the monitoring devices that should notify. The alert group must send both alert and recovery (ALL CLEAR) notifications so Flashduty can close alerts automatically.See the Dotcom-Monitor documentation HTTP Webhook Integration.
3

Verify the lifecycle

Make a monitored device fail (for example by pointing its target to a page that does not exist) and confirm Flashduty receives a Critical alert. Restore the correct address; after Dotcom-Monitor sends the recovery notification, confirm the alert closes.Back in Flashduty, the integration shows Latest event time, which confirms the setup works.

Alert key

Flashduty computes the Alert Key from the device name (device_name). Both the alert and the recovery notification of Dotcom-Monitor refer to the same monitoring device, so they land on the same Flashduty alert.
  • incident_id (@Model.CurrentState.ID) changes every time the device changes state, so the alert notification and the recovery notification carry different values. It is kept as a label and is not part of the Alert Key
  • After a device is renamed, the new name produces a new Alert Key, so an alert that was open before the rename must be closed by hand
  • Give different devices different names
Requests without device_name are rejected.

Alert lifecycle

Flashduty handles messages by the notification_type field, case-insensitively: Any other value, including TEST, is rejected with a parameter error. Dotcom-Monitor’s variables reference lists a TEST type but does not say whether the test send uses it, so Flashduty has no separate handling for it; verify with a real device state change. Repeated notifications received while the device stays in error merge into the same alert.

Status and severity

Dotcom-Monitor messages carry no severity field. A device error means the monitored target is unavailable, so it is fixed at Critical. A recovery event keeps the severity of the original alert.

Alert content

  • Title: the device name
  • Description: error type, error code, error reason and the failing target URL
  • Labels: check and device (device name), resource (failing target URL), task (task name, absent for UserView), location (monitoring location), incident_id, error_type, error_code, alert_time, report_link (online report link), source (always dotcom-monitor)
Dotcom-Monitor HTML-encodes the text it substitutes into the template; Flashduty decodes it before use.

Troubleshooting

  • A test notification returns a parameter error: a request whose notification_type is TEST is not accepted and creates no alert. This does not mean the setup is wrong; verify with a real device state change
  • Request rejected with a missing device_name or an unsupported notification_type: check that the field names in the alert template match the template above and that Data Type is Raw JSON
  • The alert does not recover: confirm the Alert Group sends recovery (ALL CLEAR) notifications and that the device name was not changed during the alert
  • integration_key invalid or a 4xx response: confirm the Webhook URL is the full push URL and the integration is not disabled