Create rules and action policies with Elastic Agent Builder

Use Elastic Agent Builder to create and configure Kibana Universal Alerting rules and action policies through natural language instead of the rule form. Describe what you want to monitor, and an agent equipped with the rule management skill resolves the data source and proposes a fully configured rule.

Before you start, make sure you have the following:

To create a rule, go to Alerting → Rules in the Observability navigation menu, or find Rules using the global search field.

Then select the creation path that lets you create the rule with an agent. Alternatively, open any agent in Elastic Agent Builder that has the rule management skill configured.

The rule management skill gives the agent domain expertise in Kibana Universal Alerting rule authoring, including knowledge of ES|QL query patterns, threshold configuration, grouping, and the Kibana Universal Alerting data model. When you describe a monitoring requirement, the agent uses its tools to resolve the relevant data source and builds a rule proposal.

The proposal appears as an inline attachment in the conversation, summarizing the rule name, type, schedule, and tags. Opening the attachment shows the full configuration across three views:

  • Conditions - The ES|QL query, thresholds, grouping criteria, and schedule the agent constructed.
  • Query preview - The results of running the proposed ES|QL query against live data, so you can evaluate whether the rule would produce meaningful signal before committing to it.
  • Runbook - A free-text runbook field associated with the rule, which the agent can populate from context in the conversation.

The agent can also search for and attach an existing rule to the conversation using the same inline attachment, opening the same view for inspection or revision.

The agent does not persist the rule automatically. Saving is an explicit action that signals the configuration is ready. Until the rule is saved, the proposal exists only in the conversation and is not evaluated against data.

When Elastic Agent Builder saves or edits a rule, Kibana automatically adds an agent-builder-assisted tag to it. The tag appears on the Rules page and works as a normal filter tag. You can remove it or edit it manually. If the agent edits the same rule later, the tag is re-applied automatically.

Use these prompts as a starting point, then adjust them to your data and thresholds:

  • Create an error threshold rule on the checkout service data. Alert when there are more than 3 HTTP 5xx errors in the past 5 minutes, grouped by URL path.
  • Monitor average CPU usage across all hosts. Alert when any host exceeds 90% for more than 10 minutes.
  • Alert when log volume from the payments service drops below 100 events in a 5-minute window. This likely means data has stopped flowing.
  • Set up a rule that tracks error rate by service. Alert at medium severity when the rate exceeds 1%, and critical when it exceeds 5%.

After a rule is saved, you can ask the agent to configure notifications. The rule management skill handles this by creating workflows and action policies.

Note

Action policies invoke workflows for alerts only. If you ask the agent to set up notifications for a rule that doesn't open alerts, the skill explains the limitation. If the rule is still a draft in the conversation, the skill changes it so matches open alerts before you save it. If the rule is already saved, that setting can't change, so the skill offers to create a new rule with the same query and schedule that opens alerts, then set up notifications on that rule.

  • Workflows - Workflows are the delivery mechanism. They define what happens when Kibana Universal Alerting determines that a notification should be sent, such as posting to Slack, emailing a team, triggering PagerDuty, and so on.
  • Action Policies - Action policies are the gating mechanism. Kibana evaluates them against the rule's alerts and invokes the workflow for the alerts they apply to. When you create an action policy with a rule, the policy applies to that rule's alerts.
    • The agent links the policy to the rule with a routing tag. If the rule already has a routing tag that no other rule uses, the agent can reuse it. Otherwise, the agent adds a notify-<rule-name> routing tag to the rule and the policy, in lowercase with hyphens (for example, notify-high-cpu-prod). The policy also applies to alerts from any other rule with that routing tag. If the agent adds a routing tag to a rule you already saved, save the rule again so the tag takes effect.
    • The action policy references the rule by ID.

Both objects are proposed as inline attachments and must be explicitly saved before they take effect.

The three objects have a dependency chain that determines the order in which they must be saved:

  1. Rule - Save the rule first. The link between the rule and the action policy takes effect only after the rule is saved.
  2. Workflow - The action policy references the workflow as a destination. The reference must resolve to a persisted workflow.
  3. Action policy - Can only be saved after both its rule and workflow dependencies exist.
Note

Action policies saved or edited through Elastic Agent Builder also receive the agent-builder-assisted tag automatically, with the same behavior: user-editable and re-applied on subsequent agent edits.