Documentation

Kibana Alerting

Version v2.5.0 · Updated
Interactive docs View on GitHub

Kibana Alerting integration#

Receive Elastic Kibana rule actions through a Webhook connector. This integration creates/updates technical AlertGroups; it does not create Change Events or automatically declare operational Incidents.

Endpoint: POST /api/integrations/kibana

IncidentRelay route#

Create a Route with Source = Kibana Alerting and copy its intake token. Attach the required team, escalation/rotation, channels and service settings. The suggested grouping is:

["kibana_rule_id", "kibana_alert_id"]

Kibana Webhook connector#

method POST and URL:

  • In Stack Management → Connectors, create a Webhook connector using

https://incidentrelay.example.com/api/integrations/kibana

  • Add custom HTTP headers:

``text Content-Type: application/json Authorization: Bearer <incidentrelay-route-intake-token> ``

summary action. Choose the Webhook connector for the active action and enter:

  • Create or edit an alerting rule. Use For each alert, not an aggregate

``json { "rule_id": "{{rule.id}}", "alert_id": "{{alert.id}}", "space_id": "{{rule.spaceId}}", "rule_name": "{{rule.name}}", "message": "{{context.reason}}", "rule_url": "{{rule.url}}", "status": "active" } ``

context.reason may be unavailable for some rule types; you can remove it or replace it with a rule-specific variable. Kibana escapes Mustache values in Webhook connector JSON bodies by default. Avoid triple-brace insertion for untrusted text.

its rule type. Send the same rule_id, alert_id and space_id with:

  • Configure a separate recovery action for the rule, when supported by

``json "status": "recovered" ``

If your Kibana action group is configured to send recovery data, you can instead pass "action_group": "{{alert.actionGroup}}"; the normalizer maps recovered to resolved. A recovery notification must carry the same alert identity as the original active notification.

original child Alert is resolved, not replaced by a new ID.

  • Test both triggering and recovery. In the AlertGroup, confirm that the

Kibana action group names and available variables vary by rule type. Consult Kibana rule action variables and the Webhook connector guide.

Identity and delivery#

The stable dedup key is based on space_id + rule_id + alert_id plus the IncidentRelay intake Route. The message, title, severity and flapping flag never change that identity. space_id defaults to default when omitted.

Kibana's per-alert action frequency can send repeated active notifications; IncidentRelay updates the same child Alert. Explicit recovered, resolved, closed or ok notifications resolve the existing Alert. Missing notifications are not interpreted as recovery.

Only per-alert messages containing both rule_id and alert_id are accepted. Summaries without stable individual IDs return a validation error rather than creating noisy, incorrectly grouped alerts.

Useful optional fields#

FieldDescription
severitycritical/high/medium/warning/low/info
title, rule_name, message, reasonDisplay context
labels, teamFor service matching and Event Orchestration
rule_url, event_linkAbsolute HTTP(S) rule/alert URL
flappingKibana flapping metadata (observational; does not resolve AlertGroup)
action_groupCan distinguish recovered from active actions

Both integrations reuse existing Route tokens, RBAC, alert lifecycle, escalation, notification channels, Alert Explain and the Event Orchestration simulator. No additional secrets or database migration are needed.