Skip to main content
Use the webhook notification channel of Komodor Realtime Health Monitors to send the issues Komodor detects in your Kubernetes clusters to Flashduty On-call. One kind of monitor issue on one resource in one namespace of one cluster maps to one Flashduty alert: an open message from Komodor triggers the alert, and a closed message recovers it.

​
In Flashduty On-call

You can obtain an integration push URL in either of the following ways.

​
Use a dedicated integration

Choose this method when you do not need to route alerts to different channels.
  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select Komodor, then click Save
  4. Open the generated integration card and copy the Push URL

​
Use a shared integration

Choose this method when you need to route alerts to different channels based on the payload.
  1. In the Flashduty console, select Integration Center → Alert Events
  2. Select Komodor and enter an integration name
  3. Configure the default route and select a channel; after creation, add more rules under Route if needed
  4. Click Save and copy the generated Push URL

​
Prerequisites

  • The Komodor Agent is installed in your Kubernetes cluster, and the cluster appears in the Komodor console.
  • Your account can edit Komodor Health Policies.

​
In Komodor

1

Open a monitor

Sign in to the Komodor console and open Organization Settings → Health Policies → Realtime Monitors. Expand the cluster and a monitor type (for example Availability monitor), then click a monitor (for example Default Runtime Availability) to open Edit Monitor, or click + Add Monitor to create one.
2

Add a webhook notification channel

  1. Under Where do you want to receive notifications?, select Webhook
  2. Click Add New Webhook:
    • Webhook URL: the full Flashduty push URL, including the integration_key parameter
    • Webhook Name: a recognizable name, for example Flashduty
    • Leave Headers empty
  3. Click Test Webhook (see the next step), then Add Webhook
  4. Select Flashduty under Select webhooks and click Save Monitor
Once created, the webhook can be selected in any other monitor. Select it in every monitor that should send alerts to Flashduty.
3

Confirm delivery

Test Webhook posts {"type":"Test!"} from your browser. Flashduty returns success and creates no alert, so the test only confirms that the push URL is reachable.The next time the monitor detects an issue, check that the alert appears in the channel’s alert list in Flashduty, and that it recovers once the issue is resolved.
Deploy monitor notifications describe a rollout (successful or failed), not a health issue, and are never followed by a recovery message. Flashduty acknowledges them without creating an alert. Send deployment records through a change integration instead.

​
Alert Key

Flashduty builds the Alert Key from the monitorType, cluster, namespace, and resourceName fields. For one kind of issue on one resource, the open and closed messages carry the same four values, so they merge into one alert and the closed message recovers it.
  • Different resources, namespaces, or clusters, or different monitor types on the same resource (for example Availability and Job), produce different alerts.
  • Changes to the issue details (issueDetails), the issue link (issueURL), and the time fields do not change the Alert Key.
  • Node issues have no namespace; an empty namespace still produces a valid Alert Key.

​
Status and severity

Komodor webhook notifications carry no severity field, so Flashduty uses Critical for every issue. If status has any other value, or monitorType, cluster, or resourceName is missing, Flashduty returns an error and Komodor records a failed delivery.

​
Labels

The alert title is <monitor type> issue on <resource name> (<cluster>/<namespace>), and the description contains the issue details and the Komodor link.

​
FAQ

No. Notification sinks deliver agent run and investigation events (such as run.finished and incident.triaged), and Komodor does not document an issue ID field for them, so a trigger and its recovery cannot be guaranteed to merge into one alert. Use the Realtime Health Monitors webhook notification described on this page.
  • Check that the monitor rule still selects the Flashduty webhook channel. After a rule is changed or deleted, Komodor no longer sends its closed message.
  • On the alert details page, compare the check, cluster, namespace, and resource labels. The recovery message must carry the same four values to recover the alert.
  • Changing the scope of an Availability monitor can remove existing issues, and Komodor may then send no closed message. Close the alert in Flashduty by hand.
Different monitor types produce different alerts. For example, when a CronJob triggers both the Availability and the CronJob monitors, Flashduty creates two alerts, and each recovers with its own closed message.
For more on monitor types and trigger conditions, see the Realtime Health Monitors and Webhook articles in the Komodor Help Center.