Elastic Alerts to On-Call

Kibana alerting rules become CallHeim alerts: repeats on the same rule collapse onto one incident, and the service the integration is bound to pages whoever is on call for it. CallHeim includes a payload mapping for Elastic’s webhook format, built and tested against sample payloads.

How the alert reaches on-call

Step 1A Kibana alerting rule's condition matches and it runs its actions.
Step 2Kibana's Webhook connector renders your body template with the rule's context and POSTs it to your CallHeim ingest URL.
Step 3CallHeim reads the rule's id as the identity signal and maps a severity word from the rendered body.
Step 4Repeats on the same rule within five minutes collapse onto one incident.
Step 5The integration's bound service selects an escalation policy, which pages the on-call tier.

Setting it up

01
Create a Webhook connector in Kibana.
Stack Management > Connectors > Create connector > Webhook, or add it directly from a rule's Actions tab.
02
Enter your CallHeim ingest URL.
Create the Elastic integration in CallHeim first to get the exact ingest URL. Set authentication to none unless you need it for network access control on your side.
03
Write a custom JSON body using Kibana's Mustache template syntax.
Kibana requires a body for a webhook action — a bare connector sends nothing usable on its own. Template it from rule.name, context.message and a severity value (severity or kibana.alert.severity), since those are the fields the CallHeim parser reads.
04
Add the connector as an action on the alerting rule.

Example payloadJSON

{
  "rule": { "id": "rule-77", "name": "CPU usage high" },
  "severity": "critical",
  "context": { "message": "CPU usage is 95% on node-3" }
}

Example shape written by us, in the fields our body template asks Kibana to render; check Elastic's own documentation for the full context-variable list.

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload field	Maps to	Note
rule.name / ruleName / name	incident title
severity / "kibana.alert.severity" (critical / high / medium / low)	severity	critical→P1, high→P2, medium→P3, low→P4; alert.actionGroup of "recovered" overrides this to P4.
context.message / reason / message	incident body
rule.id (or ruleId)	identity signal

How CallHeim processes it

Routing

Each alert source is bound to a service, and the service’s escalation policy (or its team’s) sets who is paged.

Deduplication

Repeats of the same alert collapse onto one incident while they keep arriving within five minutes of each other. A repeat that arrives after a longer quiet gap opens a new incident. Identity is the alerting rule's own id, so repeated firings of the same rule collapse.

Recovery

A recovered action group does not close the incident. CallHeim writes P4 when the alert's actionGroup is recovered, but that field is nested and not one the generic close detector reads at the top level, so the incident itself stays open until a person resolves it.

Troubleshooting

Common problems and how to fix them
Problem	Fix
The body is empty or a template error.	Kibana requires a JSON body template on a webhook action — a connector with no template sends nothing usable (see setup).
HTTP 400 on send.	Mustache auto-escapes template variables; a raw quote inside context.message can still break the surrounding JSON if the template was not written carefully — preview it in Kibana before saving.
A recovered alert stays open.	Expected — see Recovery above.
Every alert lands at P3.	Neither severity nor kibana.alert.severity was populated in the rendered body — check the template references one of them.
HTTP 401 once you enabled signing.	Kibana's webhook connector supports custom headers (as config or secret type), so add X-ItOnCall-Signature there if you enable signing.

Security

CallHeim verifies an HMAC-SHA256 signature on each source’s requests once you enable signing on that integration (the sending tool must be able to sign). Kibana's webhook connector supports custom headers, so you can add X-ItOnCall-Signature there if you enable signing. Until you do, the ingest URL itself is the credential.

Vendor documentation checked

Elastic: Webhook connector and action — checked 2026-09-24

The thresholds it passes through

Dedup window: 300s
Flap threshold: 4 transitions / 600s
Title correlation: similarity ≥ 0.6, same source and service
Group window default: 600s

All defaults are published. You can turn title correlation off or change its threshold, and set the window on your own noise rules; the dedup window and the flap settings are fixed. How alerts are processed →

Send Elastic / Kibana alerts to on-call with CallHeim.