Kibana Alerting Rules
Create, update, and lifecycle-manage Kibana alerting rules through the REST API or Terraform as code.
Overview
kibana-alerting-rules is an agent skill for the Operate phase that guides creating and managing Kibana alerting rules via REST API or Terraform.
Install
npx skills add https://github.com/elastic/agent-skills --skill kibana-alerting-rulesWhat is this skill?
- Three-part rule model: conditions, schedule, and actions with alerts flowing through connectors
- REST table covers create, update, get on `/api/alerting/rule/{id}` with required `kbn-xsrf: true` on mutating calls
- Documents API key or Basic auth plus Kibana feature privileges (Stack Rules, Actions and Connectors read)
- Supports non-default Kibana spaces via `/s/<space_id>/api/alerting` base paths
- Explicit trigger for rules-as-code and lifecycle operations (enable, disable, mute, snooze)
- Documented alerting REST operations table includes create (POST), update (PUT), and get (GET) on `/api/alerting/rule/{id
Adoption & trust: 1.1k installs on skills.sh; 502 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need reliable, automatable Kibana alert rules but keep missing `kbn-xsrf`, space paths, or the right Kibana feature privileges on API calls.
Who is it for?
Solo builders or tiny teams operating Elastic Observability or Security stacks who want rules-as-code and API-driven lifecycle control.
Skip if: Teams with no Kibana deployment, or builders only designing UIs without touching alerting APIs or infrastructure.
When should I use this skill?
Creating, updating, or managing Kibana alerting rule lifecycle (enable, disable, mute, snooze) or rules-as-code workflows via REST or Terraform.
What do I get? / Deliverables
You can create, update, and control rule lifecycle (enable, disable, mute, snooze) with authenticated API or Terraform workflows aligned to Elastic’s alerting model.
- Kibana alerting rule definitions created or updated via API or Terraform
- Lifecycle state changes (enabled, muted, snoozed) applied to existing rules
Recommended Skills
Journey fit
Operate is the canonical phase because the skill covers production alerting—conditions, schedules, actions, mute, and snooze—not product discovery or feature coding. Monitoring is the right subphase for rules-as-code and connector-backed alert actions on running Elastic stacks.
How it compares
Kibana alerting API and IaC patterns—not generic log tailing or application-level error tracking SDKs.
Common Questions / FAQ
Who is kibana-alerting-rules for?
Developers and operators who manage Elastic/Kibana environments and need programmatic control over alerting rules and their lifecycle.
When should I use kibana-alerting-rules?
In Operate when creating or updating rules, attaching actions via connectors, muting or snoozing alerts, or codifying rules in Terraform against a running Kibana URL.
Is kibana-alerting-rules safe to install?
The skill describes mutating production APIs; review the Security Audits panel on this page and scope agent credentials to least-privilege Kibana roles.
SKILL.md
READMESKILL.md - Kibana Alerting Rules
# Kibana Alerting Rules ## Core Concepts A rule has three parts: **conditions** (what to detect), **schedule** (how often to check), and **actions** (what happens when conditions are met). When conditions are met, the rule creates **alerts**, which trigger **actions** via **connectors**. ## Authentication All alerting API calls require either API key auth or Basic auth. Every mutating request must include the `kbn-xsrf` header. ```http kbn-xsrf: true ``` ## Required Privileges - `all` privileges for the appropriate Kibana feature (e.g., Stack Rules, Observability, Security) - `read` privileges for Actions and Connectors (to attach actions to rules) ## API Reference Base path: `<kibana_url>/api/alerting` (or `/s/<space_id>/api/alerting` for non-default spaces). | Operation | Method | Endpoint | | ----------------- | ------ | ---------------------------------------------------------- | | Create rule | POST | `/api/alerting/rule/{id}` | | Update rule | PUT | `/api/alerting/rule/{id}` | | Get rule | GET | `/api/alerting/rule/{id}` | | Delete rule | DELETE | `/api/alerting/rule/{id}` | | Find rules | GET | `/api/alerting/rules/_find` | | List rule types | GET | `/api/alerting/rule_types` | | Enable rule | POST | `/api/alerting/rule/{id}/_enable` | | Disable rule | POST | `/api/alerting/rule/{id}/_disable` | | Mute all alerts | POST | `/api/alerting/rule/{id}/_mute_all` | | Unmute all alerts | POST | `/api/alerting/rule/{id}/_unmute_all` | | Mute alert | POST | `/api/alerting/rule/{rule_id}/alert/{alert_id}/_mute` | | Unmute alert | POST | `/api/alerting/rule/{rule_id}/alert/{alert_id}/_unmute` | | Update API key | POST | `/api/alerting/rule/{id}/_update_api_key` | | Create snooze | POST | `/api/alerting/rule/{id}/snooze_schedule` | | Delete snooze | DELETE | `/api/alerting/rule/{ruleId}/snooze_schedule/{scheduleId}` | | Health check | GET | `/api/alerting/_health` | ## Creating a Rule ### Required Fields | Field | Type | Description | | -------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | string | Display name (does not need to be unique) | | `rule_type_id` | string | The rule type (e.g., `.es-query`, `.index-threshold`) | | `consumer` | string | Owning app: `alerts`, `apm`, `discover`, `infrastructure`, `logs`, `metrics`, `ml`, `monitoring`, `securitySolution`, `siem`, `stackAlerts`, `uptime` | | `params` | object | Rule-type-specific parameters | | `schedule` | object | Check interval, e.g., `{"interval": "5m"}`