Skip to main content
Checkmk has no generic webhook notification method. This integration provides a notification script: for every notification Checkmk sends, the script posts the notification context (all NOTIFY_* variables) to Flashduty as JSON. Each Checkmk host or service maps to one Flashduty alert: it triggers when a problem occurs and closes automatically on recovery.

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 Checkmk 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 Checkmk 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 Checkmk

The steps below are based on Checkmk 2.5. Menu names may differ slightly in other 2.x versions. The script only needs the Python 3 that ships with Checkmk; nothing else has to be installed.
1

Install the notification script on the Checkmk server

Where: A terminal of the site user on the Checkmk server (for example omd su mysite) › ~/local/share/check_mk/notifications/flashdutyCreate the file ~/local/share/check_mk/notifications/flashduty with the following content:
Then make it executable:
The comment # Flashduty on the second line is the name Checkmk shows for the script. The push URL is passed as the script’s first parameter and is not included in the request body. On a network error, or when Flashduty returns 5xx or 429, the script exits with code 1 and Checkmk retries later. Other errors exit with code 2 and are not retried.
In a distributed setup, install the script on every site that sends notifications. If notification forwarding is enabled, the central site is enough.
2

Create a notification rule

Where: Checkmk › Setup › Events › Notifications › Add notification ruleComplete the wizard:Keep the defaults for the remaining steps and save the rule. If the page shows pending changes, click Activate changes.
Checkmk runs the notification script once for each contact the rule selects. With several contacts, the same notification is posted several times. The posts land on the same alert but create duplicate events, so select only one user under Recipient.
3

Verify the alert and its recovery

Where: Checkmk › Setup › Events › Notifications › Test notifications; real alerts on the details page of the serviceThe test notification from Test notifications carries Checkmk’s test marker: Flashduty returns success and does not create an alert. It only proves the connection and does not replace a real alert.Put a service into WARN or CRIT for real (for example by lowering a threshold) and confirm that Flashduty receives an active alert. Then let the service recover and confirm that the alert closes.After a few seconds, go back to Flashduty. If the integration shows a Latest event time, the setup works.

Alert key

Flashduty computes the Alert Key from the host name HOSTNAME and the service name SERVICEDESC. Host notifications use an empty service name. Problem and recovery notifications for the same host or service carry the same host and service names, so they land on the same alert. When the state rises to a higher severity (for example a service going from WARN to CRIT), Flashduty opens a new alert at the higher severity and keeps the earlier alert open; the recovery notification closes both. Changes to the state, plugin output, notification number, time, host address, site, or labels do not change the Alert Key. Renaming a host or service produces a new alert; close any alert left open under the old name by hand. Flashduty rejects a request that lacks HOSTNAME, WHAT, the current state, or NOTIFICATIONTYPE, and a service notification that lacks SERVICEDESC.

Alert lifecycle

Checkmk sends a recovery notification only after it has sent a problem notification. Acknowledgement, downtime, flapping, and custom notifications are also sent when the problem notification was suppressed (for example while a service flaps). An alert opened from them would never get a recovery notification to close it. So only problem notifications open alerts, and Flashduty handles each notification type NOTIFICATIONTYPE as follows: While a service flaps, Checkmk sends no state change notifications: a return to OK during flapping sends no recovery notification, and none is sent after flapping ends. That is why the rule must include Start or end of flapping state and Start or end of downtime: the notification at the end of flapping or downtime closes an alert that has already recovered. Ignored notifications get a success response, so Checkmk does not retry them.

Status and severity

Severity comes from the current state: SERVICESTATE for service notifications and HOSTSTATE for host notifications. A recovery event takes the severity of the hard state before recovery (PREVIOUSSERVICEHARDSTATE or PREVIOUSHOSTHARDSTATE).

Alert content

  • Title: <service name> on <host name> for service notifications, Host <host name> for host notifications
  • Description: the plugin output SERVICEOUTPUT or HOSTOUTPUT, followed by the long output when present
  • Labels: host, resource (host name), service, check (service name, service notifications only), what (HOST or SERVICE), notification_type, state, site, host_alias, host_address, host_groups, service_groups (service notifications only), and Checkmk host and service labels: HOSTLABEL_env becomes host_label_env and SERVICELABEL_app becomes service_label_app, with characters such as / and . in the key replaced by _
Each alert carries at most 50 labels. When there are more, labels beyond the limit are dropped in name order. Contact details such as contact names and email addresses are not written to labels.

Troubleshooting

  • Flashduty is not listed as a method in Checkmk: make sure the script is in the site’s local/share/check_mk/notifications/ directory, is named flashduty, is executable, and has # Flashduty on its second line
  • No notification is sent: check the site’s var/log/notify.log to confirm the rule matched the event and that the user under Recipient has not disabled notifications
  • The script reports HTTP 4xx: make sure parameter 1 is the full push URL including integration_key
  • The same notification is posted several times: Recipient selects several contacts; select only one user
  • The alert does not recover: make sure the object has really returned to OK or UP. If the problem happened during flapping or downtime, make sure the rule includes Start or end of flapping state and Start or end of downtime
For the meaning of the notification context variables, see the Checkmk documentation on Notifications.