Skip to content

[Alerting V2][Serverless & 9.5][M2] Edit and improve get-started docs; address issues #1419 and #1420 #7213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
nastasha-solomon merged 2 commits into from
Jul 5, 2026
Merged

[Alerting V2][Serverless & 9.5][M2] Edit and improve get-started docs; address issues #1419 and #1420 #7213

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
35791b2
RBAC and tutorial
nastasha-solomon Jul 5, 2026
44c567e
add applies to
nastasha-solomon Jul 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions explore-analyze/alerting/kibana-alerting-experimental/get-started.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,13 +6,13 @@ applies_to:
products:
- id: kibana
- id: cloud-serverless
description: "Enable the experimental alerting system in Kibana, configure role access, and create your first rule."
description: "Get started with the experimental alerting system in Kibana: review requirements, enable the system, configure role access, and follow a tutorial to create a rule and observe the alert lifecycle."
---

# Get started with the {{alerting-v2-system}} [alerting-v2-get-started]

Use these guides to get the {{alerting-v2-system}} running in your space, set up role access for your team, and create your first rule.

- [Turn on the {{alerting-v2-system-cap}}](get-started/setup.md): Enable the `alerting:v2:enabled` advanced setting and confirm the system is accessible in your space.
- [Configure access](get-started/configure-access.md): Set up a role with the {{kib}} feature privileges and {{es}} index privileges needed to create rules and query alert data.
- [Create your first rule](get-started/create-your-first-rule.md): A hands-on tutorial that walks you through loading sample data, creating a rule, and watching the alert lifecycle play out from breach to recovery.
- [Set up the {{alerting-v2-system-cap}}](get-started/setup.md): Review requirements, enable the `alerting:v2:enabled` advanced setting, and confirm the system is accessible in your space.
- [Configure access](get-started/configure-access.md): Set up a role with the {{kib}} feature privileges needed to create rules, triage alerts, and query alert data.
- [Create your first rule](get-started/create-your-first-rule.md): A hands-on tutorial that walks you through loading sample data, creating a rule, and observing the alert lifecycle from breach through automatic recovery.
32 changes: 23 additions & 9 deletions ...e-analyze/alerting/kibana-alerting-experimental/get-started/configure-access.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,8 @@ The following table shows the minimum privileges required for each activity. Hig
| Monitor rule execution | **Execution history: Read** (under **Alerting**) |
| Triage alert episodes | **Alerts: All** (under **Alerting**) |
| Configure notifications | **Action Policies: All** (under **Alerting**) + **Workflows: Read** (under **Analytics > Workflows**) |
| Query rule and episode data in Discover | **Discover: Read** (under **Analytics > Discover**) + `read` index privilege on the relevant data stream |
| Query `.rule-events` and `.alert-actions` in Discover | **Discover: Read** (under **Analytics > Discover**) + **Alerts: Read** (Elasticsearch `read` access is bundled automatically) |
| Query `.kibana-event-log-*` in Discover | **Discover: Read** (under **Analytics > Discover**) + custom role with `read` index privilege on `.kibana-event-log-*` |

## Author and monitor rules [alerting-authoring-monitoring-privileges]

Expand Down Expand Up @@ -66,6 +67,10 @@ The **Alerts** privilege controls who can take triage actions on alert episodes.
| **All** | Acknowledge, snooze, assign, tag, activate, and deactivate alert episodes |
| **Read** | View alert episodes |

:::{note}
Granting **Alerts: All** or **Alerts: Read** also gives the role direct Elasticsearch `read` access to `.rule-events` and `.alert-actions`, scoped to that role's spaces. This is bundled into the privilege — no separate custom role or index privilege is needed to query these data streams in Discover.
:::

## Configure notifications [alerting-notifications-privileges]

These privileges control who can set up the action policies and workflows that route alert episode notifications.
Expand Down Expand Up @@ -109,16 +114,25 @@ Both levels grant the same query access. There is no write surface for any of th

### {{es}} index access

Each data source requires a separate `read` index privilege:
For `.rule-events` and `.alert-actions`, Elasticsearch `read` access is bundled into the **Alerts** Kibana privilege — nothing extra to configure. For `.kibana-event-log-*`, a custom role is still required.

| Data source | What it stores | Required privilege |
| Data source | What it stores | How to grant access |
|---|---|---|
| `.rule-events` | A record for every rule evaluation — one document per result row per run | `read` |
| `.alert-actions` | Episode action records: acknowledge, snooze, resolve, assign, and other triage operations | `read` |
| `.kibana-event-log-*` | Action policy dispatch outcomes written by the dispatcher: `dispatched`, `throttled`, and `unmatched` | `read` |
| `.rule-events` | A record for every rule evaluation; one document per result row per run | Automatic with **Alerts: All** or **Alerts: Read**. If access is missing, grant `read` using a custom role as a fallback. |
| `.alert-actions` | Episode action records: acknowledge, snooze, resolve, assign, and other triage operations | Automatic with **Alerts: All** or **Alerts: Read**. If access is missing, grant `read` using a custom role as a fallback. |
| `.kibana-event-log-*` | Action policy dispatch outcomes written by the dispatcher: `dispatched`, `throttled`, and `unmatched` | Custom role with `read` index privilege. Not covered by the automatic grant. |

## Next steps [alerting-access-next-steps]

Because `.rule-events` and `.alert-actions` are hidden system data streams, request access through a custom role with the appropriate index privileges.
With access configured, you're ready to start using the {{alerting-v2-system}}:

<!-- TODO: Uncomment when PR #6527 (alerts) is merged, and add as a link in the note under the Rules section:
For step-by-step instructions, refer to [Create a rule from Discover](../alerts/query-alerts-and-signals-in-discover.md).
- **[Create your first rule](create-your-first-rule.md):** Follow the tutorial to create an ES|QL rule, load sample data, and watch the alert episode lifecycle from breach through automatic recovery.

<!-- TODO: Uncomment when PR #6523 (rules) is merged:
- **[Create a rule](../rules/create-a-rule.md):** Write the {{esql}} query that defines what to detect, choose Signal or Alert mode, and configure grouping and thresholds.
-->
<!-- TODO: Uncomment when PR #6525 (workflows/notifications) is merged:
- **[Set up workflows](../workflows-alerting.md):** Configure the automation objects that deliver notifications — email, Slack, webhook, and so on.
- **[Create action policies](../action-policies/create-configure-action-policy.md):** Define who gets notified, how often, and under what conditions.
-->

Loading
Loading