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 get the integration push URL in either of the following ways.

Use a dedicated integration

Choose this option if all alerts go to one channel. It’s the simpler setup.
  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select Komodor, then click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

Choose this option if you need to route alerts to different channels based on the alert payload.
  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Komodor 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

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 in Komodor

Where: Komodor › Organization Settings › Health Policies › Realtime MonitorsExpand 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 in Komodor

Where: Komodor › Realtime Monitors › Edit Monitor › Where do you want to receive notifications? › Webhook › Add New WebhookClick Test Webhook (see the next step), then Add Webhook. Then 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. Komodor sends a closed message when the issue is resolved and Flashduty recovers the alert from it, so no separate recovery setup is needed.
3

Confirm delivery

Where: Komodor › Realtime Monitors › Edit Monitor › Add New Webhook › Test WebhookTest 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.