Kibana alerts turn Elasticsearch data into notifications when important conditions occur, so issues do not have to wait for a dashboard refresh.
Kibana alert rules run on a schedule, query indices (or a Kibana data view), evaluate a condition such as a threshold or query match, and trigger actions through connectors like webhooks. The rule evaluation runs in Kibana, while the data retrieval runs in Elasticsearch, so both services must be reachable and healthy for consistent alert execution.
Reliable alerting depends on correct index permissions, a consistent time field in the data, and sensible rule intervals and thresholds. Overly aggressive settings can generate noisy alerts or overwhelm connectors, while missing authentication or TLS settings can prevent queries and leave the rule perpetually failing.
Steps to create Kibana alerts from Elasticsearch data:
- Confirm Elasticsearch returns documents for the index pattern used by the alert rule.
$ curl --silent --show-error --cacert /etc/elasticsearch/certs/http-ca.crt --user elastic:password "https://localhost:9200/logs-*/_count?pretty" { "count" : 9131, "_shards" : { "total" : 3, "successful" : 3, "skipped" : 0, "failed" : 0 } }Match the rule time window by validating a filtered query before relying on the total count.
Prefer --cacert with the cluster CA certificate for routine checks.
- Create a webhook connector in Kibana under Stack Management → Rules and Connectors → Connectors.
Webhook targets receive alert context data, so an untrusted URL can leak internal details.
Use a test endpoint that can receive JSON payloads before targeting production systems.
- Create the alert rule in Kibana for the target index pattern or data view.
Set the rule time window larger than the check interval to tolerate ingest lag without missing events.
Related: How to create a Kibana alert rule
- Copy the rule ID from the rule details page URL in Kibana.

- Fetch the rule execution status from the Kibana alerting API.
$ curl --silent --show-error --cacert /etc/kibana/certs/kibana-ca.crt --user elastic:password --header "kbn-xsrf: true" "https://localhost:5601/kibana/api/alerting/rule/6b1c65ff-7f45-4e38-84e5-5365a1c606a2" | jq '{id: .id, enabled: .enabled, execution_status: {status: .execution_status.status}}' { "id": "6b1c65ff-7f45-4e38-84e5-5365a1c606a2", "enabled": true, "execution_status": { "status": "ok" } }Using the elastic superuser in scripts risks credential leaks and over-privilege.
execution_status changes to error when rule execution fails.
- Review the rule Event log tab to confirm recent checks and action outcomes.
Failures typically include a connector error message that maps directly to the misconfiguration.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
