Elastic alert integration

Use the Kibana Webhook connector to send alerts from Kibana rules (Stack Management rules, Observability rules, and Security detection rules) to Flashduty On-call. Each Kibana alert (rule plus alert ID) maps to one Flashduty alert: repeat notifications while the alert is active merge into it, and the Recovered notification from Kibana recovers it. This integration works with Elastic Cloud, Elastic Cloud Serverless, and self-managed Kibana 8.x and later. If you run the self-managed ElastAlert 2 rule engine, use the ElastAlert 2 integration instead.

Prerequisites

Subscription: the Kibana Webhook and PagerDuty connectors require an Elastic Gold subscription or higher (Basic does not include them); a 30-day trial license also works. See Elastic subscriptions.
Network: Kibana must be able to reach the Flashduty push URL. If your self-managed Kibana sets xpack.actions.allowedHosts in kibana.yml, add the push URL’s host name (for example api.flashcat.cloud) to that list, otherwise the connector refuses to send.
Permissions: you need Kibana privileges to create connectors and edit rules. See Alerting security.

In Kibana

Create a Webhook connector

Where: Kibana › Stack Management › Connectors › Create connector › Webhook (on some 8.x versions: Stack Management › Alerts and Insights › Connectors)

Field	Value
Name (required)	For example `Flashduty`
Method (required)	`POST`
URL (required)	`{integration_url}` (it already includes the `integration_key` parameter)
Authentication (required)	`None`; the `integration_key` in the push URL authenticates the request
HTTP headers (required)	Add `Content-Type: application/json`

Click Save.

Add an action to the rule

Where: Kibana › edit or create a rule › Actions › select the Flashduty connector

Field	Value
Action frequency (required)	For each alert. With Summary of alerts, Kibana provides no `alert.id` and Flashduty rejects the request
Run when (required)	The rule’s alert action group (such as `Alert`, `Query matched`, or `Threshold met`); On status changes is the recommended notification timing
Body (required)	Paste the “Action template” below

Add a second action for Recovered

Where: Kibana › edit or create a rule › Actions › Add action

Field	Value
Connector (required)	The same `Flashduty` connector
Action frequency (required)	For each alert
Run when (required)	Recovered
Body (required)	Paste the same template

Kibana sends recovery notifications through a separate action. Without a Recovered action, Flashduty never receives the recovery and the alert stays active.

Some rules have several alert action groups, for example Alert and Warning on a Metric threshold rule, or Critical, High, Medium, and Low on an SLO burn rate rule. Add one action per action group and set the matching severity in its template.

Verify the lifecycle

Where: Kibana › Stack Management › ConnectorsLet the rule match its condition, and confirm that Flashduty receives an active alert. Then let the data return to normal, and confirm that the same alert recovers. A few seconds later the integration in Flashduty shows a Latest event time, which means setup works.The connector’s Test tab sends the body you type without rendering rule or alert variables. It only proves that the push URL is reachable. If you paste the template below into Test, Flashduty receives the literal {{rule.id}} and {{alert.id}} and opens an active alert titled {{rule.name}}; change action_group in the body to recovered and click Run again to recover that test alert.

Action template

Paste the following JSON into the Body of every action:

{
  "rule_id": "{{rule.id}}",
  "rule_name": "{{rule.name}}",
  "rule_type": "{{rule.type}}",
  "rule_tags": "{{rule.tags}}",
  "rule_url": "{{rule.url}}",
  "space_id": "{{rule.spaceId}}",
  "alert_id": "{{alert.id}}",
  "alert_uuid": "{{alert.uuid}}",
  "action_group": "{{alert.actionGroup}}",
  "action_group_name": "{{alert.actionGroupName}}",
  "severity": "Critical",
  "reason": "{{context.reason}}",
  "alert_details_url": "{{context.alertDetailsUrl}}",
  "kibana_base_url": "{{kibanaBaseUrl}}"
}

Field	Description
`rule_id`, `alert_id`	Required. Together they form the Alert Key; do not change them
`action_group`	Required. Flashduty uses it to detect recovery notifications; do not change it
`severity`	Alert severity. Set `Critical`, `Warning`, or `Info` per action group; Security detection rules can use `{{context.rule.severity}}`
`reason`	Alert description. Observability rules provide `{{context.reason}}`; for Stack rules such as Elasticsearch query or Index threshold, use `{{context.message}}` instead
`alert_details_url`	Alert details link from Observability rules; empty for other rule types
`rule_url`, `kibana_base_url`	Empty unless `server.publicBaseUrl` is configured in Kibana

Kibana JSON-escapes variables in the Body, so quotes or line breaks in rule names or descriptions do not break the JSON.

Custom labels

To turn fields from the rule context into Flashduty labels (for routing or noise reduction), add a custom_labels object to the template, for example:

"custom_labels": {
  "host": "{{context.group}}",
  "env": "production"
}

Custom and built-in labels together are limited to 50. Keys may contain only letters, digits, and underscores and must not start with a digit. A built-in label overrides a custom label with the same key.

Alert key

Flashduty builds the Alert Key from rule_id and alert_id.

rule.id uniquely identifies the rule.
alert.id is the ID of a single alert produced by the rule. For rules grouped by a field it is the group value (such as a host name); for ungrouped rules it is usually a fixed value (such as *). It does not change while an alert goes from active to Recovered.
Kibana’s own PagerDuty connector uses <rule ID>:<alert ID> as its default dedup key to tie an alert’s trigger and resolve together, the same pairing this integration uses.

alert.uuid stays the same while an alert is active, and a new UUID is generated when the same alert.id fires again after recovering. Flashduty stores it only as the alert_uuid label so you can find that occurrence in Kibana. After a Flashduty alert recovers, the next trigger with the same Alert Key opens a new alert, so keying on alert.id also gives one Flashduty alert per occurrence. Changes to the rule name, tags, severity, description, or action group do not change the Alert Key. For example, when a Metric threshold rule’s group moves from Warning to Alert, both notifications carry the same Alert Key.

Status and severity

Condition	Flashduty status or severity
`action_group` is `recovered`	Recovered
`action_group` is `notGeoContained` (recovery action group of the Tracking containment rule)	Recovered
`severity` is `Critical` or `high`	Critical
`severity` is `Warning`, `medium`, or empty	Warning
`severity` is `Info` or `low`	Info

severity is case-insensitive. Any other value is rejected so that a typo cannot produce the wrong severity. Security detection rules do not send Recovered notifications. Each detection alert becomes a separate Flashduty alert that you close manually or through auto-close in Flashduty.

Use the PagerDuty connector (optional)

If your rules already use the Kibana PagerDuty connector, you can point it at the Flashduty PagerDuty Compatible integration without rewriting the actions. Alerts sent this way arrive through Flashduty’s PagerDuty Compatible integration, not the Elastic integration on this page.

Add a PagerDuty Compatible integration in Flashduty and copy its push URL
Create a PagerDuty connector in Kibana: set API URL to that push URL (that is, {integration_url}) and Integration Key to the integration key from the push URL
In the rule, use For each alert. Add an action with Event action Trigger for the alert action group, and one with Event action Resolve for Recovered. The Recovered action defaults to Resolve
Keep the DedupKey that Kibana pre-fills, {{rule.id}}:{{alert.id}}, on both actions and do not clear it, so the resolve event closes the matching alert. With an empty DedupKey on the Trigger action, Kibana sends no dedup_key, Flashduty generates a random Alert Key for each trigger, and the resolve event cannot close it

Troubleshooting

Kibana reports target url "..." is not added to the Kibana config xpack.actions.allowedHosts: add the Flashduty push URL’s host name to xpack.actions.allowedHosts
Flashduty returns an error starting with alert_id is required: the action’s Action frequency is Summary of alerts; change it to For each alert
Flashduty returns rule_id is required: the Body is not the template on this page, or rule_id was changed
Alerts do not recover: make sure a Recovered action exists and the Body keeps "action_group": "{{alert.actionGroup}}"
Alerts for different hosts merge into one: make sure the rule groups by a field (Group by) and the Body keeps {{alert.id}}
Flashduty returns severity ... is not supported: severity must be Critical, Warning, or Info, or critical, high, medium, or low from Security rules

For field details, see the Elastic documentation on rule action variables, the Webhook connector, and the PagerDuty connector.

Quick Start

Product Comparison

Channels

Incident Management

Post-Mortem

Status Page

Analytics

Integration Settings

Configuration

Advanced

Integrations

Best Practices

In Flashduty On-call

Use a dedicated integration

Use a shared integration

Prerequisites

In Kibana

Action template

Custom labels

Alert key

Status and severity

Use the PagerDuty connector (optional)

Troubleshooting

​In Flashduty On-call

​Use a dedicated integration

​Use a shared integration

​Prerequisites

​In Kibana

​Action template

​Custom labels

​Alert key

​Status and severity

​Use the PagerDuty connector (optional)

​Troubleshooting

In Flashduty On-call

Use a dedicated integration

Use a shared integration

Prerequisites

In Kibana

Action template

Custom labels

Alert key

Status and severity

Use the PagerDuty connector (optional)

Troubleshooting