Alerting_v2: Dispatcher notification policy by kdelemme · Pull Request #252758 · elastic/kibana

kdelemme · 2026-02-11T16:48:04Z

Resolves https://github.com/elastic/rna-program/issues/117
Resolves https://github.com/elastic/rna-program/issues/118

Dispatcher and Notification Policy Architecture

The dispatcher is the asynchronous component that bridges rule execution (alert-event production) and notification delivery. It runs as a Task Manager task on a fixed 5-second polling interval, processes batches of up to 10,000 alert episodes (due to ES|QL limits), applies suppression and throttling logic, evaluates notification policies, and dispatches matched episodes to workflows. All decisions are recorded back to .alerts-actions so subsequent runs skip already-handled episodes.

We leverage a pipeline pattern like the Rule Executor

Out of scope for this PR

Using workflow will be tackle in a follow-up. We are only logging for now.
NotificationPolicy schema will change with chore(rna): update notification policy #253134.
Handle API Key lifecycle and storage in the Notification Policy:
- Encrypt
- Handle UIAM keys
- Store other metadata like owner
- Revoke keys on Notification Policy deletion

Decision that can be revisited

Some Steps uses extracted function, mainly to make testing easier

Dispatcher pipeline

The dispatcher executes a 10-step pipeline on every tick. The steps are sequential -- each depends on the output of the previous one.

flowchart TD
    S1["1. Fetch alert episodes"] --> S2["2. Fetch suppressions"]
    S2 --> S3["3. Apply suppressions"]
    S3 --> S3a["suppressed episodes"]
    S3 --> S3b["dispatach-able episodes"]
    S3b --> S4["4. Fetch rules"]
    S4 --> S5["5. Fetch notification policies"]
    S5 --> S6["6. Evaluate matchers"]
    S6 --> S7["7. Build notification groups"]
    S7 --> S8["8. Apply throttling"]
    S8 --> S8a["throttled groups"]
    S8 --> S8b["dispatch groups"]
    S8b --> S9["9. Dispatch to workflows"]
    S9 --> S10["10. Record outcomes to .alerts-actions"]
    S3a --> S10
    S8a --> S10

Detailed steps

Step 1: Fetch alert episodes

Runs getDispatchableAlertEventsQuery() via ES|QL against both .alerts-events and .alerts-actions. The query uses INLINE STATS to compute the last_fired timestamp per (rule_id, group_hash) from existing fire/suppress actions, then filters to only include alert events newer than last_fired. A lookback window of previousStartedAt - 10 minutes is applied as a time range filter. Results are sorted by last_event_timestamp ascending and capped at 10,000 rows.

Output: AlertEpisode[] (up to 10,000).

Step 2: Fetch suppressions

Using the alert episodes from step 1, runs getAlertEpisodeSuppressionsQuery() against .alerts-actions only. This resolves the latest ack/unack, deactivate/activate, and snooze/unsnooze state per (rule_id, group_hash, episode_id).

Output: AlertEpisodeSuppression[].

Step 3: Apply suppressions

Merges suppression results into the alert episodes. An episode is suppressed if any of the three suppression types apply:

Suppression type	Scope	Condition
Ack	`(rule_id, group_hash, episode_id)`	`last_ack_action == "ack"`
Deactivate	`(rule_id, group_hash, episode_id)`	`last_deactivate_action == "deactivate"`
Snooze	`(rule_id, group_hash)`	`last_snooze_action == "snooze"` AND `expiry > episode.last_event_timestamp`

Snooze is scoped to the entire series (all episodes under a group_hash), while ack and deactivate are scoped to individual episodes.

Output: Two arrays -- suppressed[] (with reason) and active[].

Step 4: Fetch rules

Extracts unique rule_id values from the active episodes and batch-fetches the rule objects.

Output: Map<string, Rule> keyed by rule_id.

Step 5: Fetch notification policies

Extracts unique notification policy IDs from the fetched rules and batch-fetches the policy objects.

Output: Map<string, NotificationPolicy> keyed by policy_id.

Step 6: Evaluate matchers

For each active episode, iterates through the notification policies associated with its rule. A policy with an empty/undefined matcher is a catch-all that matches every episode. When a matcher is defined, it is evaluated as a KQL expression against the episode object using evaluateKql() from @kbn/eval-kql.

Supported KQL features:

Field equality: episode_status: active
Wildcards: group_hash: critical*
Logical operators: AND, OR, NOT
Nested field access: data.severity: critical
Range queries: timestamp >= now-1h

An episode can match multiple policies (from the same rule). Each match is handled independently -- the episode may be dispatched to multiple workflows.

Output: MatchedPair[] (episode + policy pairs).

Step 7: Build notification groups

Groups matched pairs by (rule_id, policyId, groupKey). The notificationGroupId is an objectHash of these three fields, used as a stable identifier for throttle tracking.

When groupBy is [] (current default), each episode dispatches individually -- the group key is set to { groupHash, episodeId }, meaning one NotificationGroup per episode.

Episodes from different rules are never merged into the same group, even if they share the same policy.

Output: NotificationGroup[].

Step 8: Apply throttling

For each notification group, checks whether a notification was already sent within the policy's throttle interval. The dispatcher queries .alerts-actions for action_type: "notified" records matching the notification_group_id.

Throttling is per (rule_id, policy_id, group_key). The throttle interval defines the minimum gap between consecutive notifications for the same combination.

Timeline:  ──────────────────────────────────────────────────
           |         |         |         |         |
           t0        t1        t2        t3        t4
                     (1h interval)

  t0: Group first seen      -> FIRE (first occurrence always fires)
  t1: Group seen again (30m) -> THROTTLED (within 1h interval)
  t2: Group seen again (45m) -> THROTTLED (within 1h interval)
  t3: Group seen again (65m) -> FIRE (interval elapsed, reset)
  t4: Group seen again (80m) -> THROTTLED (within 1h of t3)

The interval resets from the timestamp of the last dispatched notification (dispatch-time based), not from the first occurrence.

Output: Two arrays -- dispatch[] and throttled[].

Step 9: Dispatch to workflows

For each non-throttled notification group, invokes the target workflow with the group's episodes as payload. Not yet implemented.

Step 10: Record outcomes

Bulk-writes action documents to .alerts-actions to record what happened to each episode:

suppress for each episode from step 3 (ack/deactivate/snooze) -- with reason
suppress for each episode in every throttled group from step 8 -- reason: "suppressed by throttled policy {policyId}"
fire for each episode in every dispatched group -- reason: "dispatched by policy {policyId}"
notified for each dispatched group itself -- used for throttle tracking on subsequent runs, keyed by notification_group_id

The fire and suppress actions carry last_series_event_timestamp to feed back into the dispatcher query's fire filter, ensuring already-processed episodes are excluded on the next tick.

Notification policy

A notification policy defines how and when to dispatch alert episodes to a workflow. Each rule references one or more notification policies via notification_policies.

Fields

Field	Type	Description
`id`	`string`	Unique identifier
`name`	`string`	Display name
`description`	`string`	Description
`matcher`	`string?`	KQL expression; empty/undefined = catch-all
`groupBy`	`string[]`	`data.*` fields to group episodes; `[]` = one notification per episode
`throttle.interval`	`string?`	Minimum gap between notifications for the same group (e.g. `"1h"`, `"5m"`)
`workflowId`	`string`	The workflow to trigger, will change in a follow-up PR

Matcher evaluation

The matcher is a KQL (Kibana Query Language) expression evaluated against the episode's fields using evaluateKql() from @kbn/eval-kql. This supports:

Simple field matching: episode_status: active
Wildcards: group_hash: prod-*
Boolean logic: episode_status: active AND rule_id: rule-001
Nested fields: data.severity: critical
Range queries: timestamp >= now-1h

If the matcher is empty or undefined, the policy acts as a catch-all and matches all episodes.

Grouping semantics

When groupBy is [], each episode becomes its own NotificationGroup with a group key of { groupHash, episodeId }. When groupBy contains field names, episodes sharing the same values for those fields (within the same rule) are batched into one notification group.

Grouping is always scoped per rule -- episodes from different rules are never merged.

Throttle semantics

Throttling is per (rule_id, policy_id, group_key), tracked via notified action records in .alerts-actions. The notification_group_id is an objectHash of these three fields, providing a stable key across dispatcher runs.

The first time a group is seen (no prior notified action), it always fires. Subsequent occurrences within the throttle window are suppressed. The window resets from the dispatch time of the last successful notification.

Outcome recording and `.alerts-actions` schema

The dispatcher writes three action types to .alerts-actions:

action_type: "fire"

Written for each episode dispatched to at least one workflow. Used by the fire filter to avoid reprocessing.

{
  "@timestamp": "2026-01-27T16:16:00.000Z",
  "actor": "system",
  "action_type": "fire",
  "rule_id": "rule-001",
  "group_hash": "rule-001-series-1",
  "last_series_event_timestamp": "2026-01-27T16:15:00.000Z",
  "source": "internal",
  "reason": "dispatched by policy policy-A"
}

action_type: "suppress"

Written for each episode suppressed by ack, deactivate, snooze, or throttle.

{
  "@timestamp": "2026-01-27T16:16:00.000Z",
  "actor": "system",
  "action_type": "suppress",
  "rule_id": "rule-002",
  "group_hash": "rule-002-series-1",
  "last_series_event_timestamp": "2026-01-27T16:15:00.000Z",
  "source": "internal",
  "reason": "ack"
}

action_type: "notified"

Written once per dispatched notification group (not per episode). Used for throttle lookups on subsequent runs.

{
  "@timestamp": "2026-01-27T16:16:00.000Z",
  "actor": "system",
  "action_type": "notified",
  "rule_id": "rule-001",
  "group_hash": "irrelevant",
  "last_series_event_timestamp": "2026-01-27T16:16:00.000Z",
  "notification_group_id": "abc123hash",
  "source": "internal",
  "reason": "notified by policy policy-A with throttle interval"
}

…n-policy

kdelemme · 2026-02-23T13:27:05Z

/ci

kdelemme · 2026-02-23T14:04:20Z

/ci

kdelemme · 2026-02-23T16:12:55Z

/ci

cnasikas

LGMT! I am almost done with the review. I will continue tomorrow with the most complex step, and I will post a last review.

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/tokens.ts

...ugins/shared/alerting_v2/server/lib/notification_policy_client/notification_policy_client.ts

cnasikas · 2026-02-26T09:57:52Z

x-pack/platform/plugins/shared/alerting_v2/server/setup/bind_services.ts

  );

  bind(RulesSavedObjectService).toSelf().inRequestScope();
+  bind(RulesSavedObjectServiceInternalToken)


What about (pseudo code)? Could that work?

bind(RulesSavedObjectServiceScopedToken).toSelf().inRequestScope(); bind(RulesSavedObjectServiceInternalToken).toSelf().inSingletonScope(); bind(NotificationPolicySavedObjectServiceScopedToken) .toDynamicValue(({ get }) => { const soClient = get(RulesSavedObjectServiceScopedToken); const spaces = get(PluginStart<AlertingServerStartDependencies['spaces']>('spaces')); return new NotificationPolicySavedObjectService(soClient, spaces); }) .inRequestScope(); bind(NotificationPolicySavedObjectServiceInternalToken) .toDynamicValue(({ get }) => { const soClient = get(RulesSavedObjectServiceInternalToken); const spaces = get(PluginStart<AlertingServerStartDependencies['spaces']>('spaces')); return new NotificationPolicySavedObjectService(soClient, spaces); }) .inSingletonScope();

If this will not work, we can follow the same example as EsServiceInternalToken and EsServiceScopedToken for the saved object client.

Why would the NotificationPolicy SO service uses the Rules SO Service? This part is not clear to me.

As for renaming the token, you're suggesting to follow XXXInternalToken (using internal dependencies) and XXXScopedToken (using request scoped dependencies)?

Renamed the token 5702779

Why would the NotificationPolicy SO service uses the Rules SO Service? This part is not clear to me.

Yes, sorry, it was a mistake by me. What I had in mind was something like this but feel free to ignore:

bind(InternalSavedObjectsClientFactory) .toResolvedValue( (savedObjects) => (includedHiddenTypes) => { const client = savedObjects.createInternalRepository(includedHiddenTypes); return () => client; }, [CoreStart('savedObjects')] ) .inSingletonScope(); bind(RulesSavedObjectService).toSelf().inRequestScope(); bind(RulesSavedObjectServiceScopedToken).toService(RulesSavedObjectService); bind(RulesSavedObjectServiceInternalToken) .toResolvedValue( (internalFactory, spaces) => new RulesSavedObjectService(internalFactory([RULE_SAVED_OBJECT_TYPE]), spaces), [ InternalSavedObjectsClientFactory, PluginStart<AlertingServerStartDependencies['spaces']>('spaces'), ] ) .inSingletonScope(); bind(NotificationPolicySavedObjectService).toSelf().inRequestScope(); bind(NotificationPolicySavedObjectServiceScopedToken).toService( NotificationPolicySavedObjectService ); bind(NotificationPolicySavedObjectServiceInternalToken) .toResolvedValue( (internalFactory, spaces) => new NotificationPolicySavedObjectService( internalFactory([NOTIFICATION_POLICY_SAVED_OBJECT_TYPE]), spaces ), [ InternalSavedObjectsClientFactory, PluginStart<AlertingServerStartDependencies['spaces']>('spaces'), ] ) .inSingletonScope();

x-pack/platform/plugins/shared/alerting_v2/server/setup/bind_services.ts

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/steps/apply_throttling_step.ts

.../platform/plugins/shared/alerting_v2/server/lib/dispatcher/steps/fetch_policies_step.test.ts

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/steps/fetch_rules_step.test.ts

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/dispatcher.test.ts

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/execution_pipeline.ts

…n-policy

cnasikas

LGMT!

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/steps/fetch_rules_step.test.ts

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/steps/apply_throttling_step.ts

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/steps/record_actions_step.ts

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/dispatcher.test.ts

cnasikas · 2026-02-27T15:57:55Z

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/types.ts

+  updatedAt: string;
+}
+
+export interface NotificationPolicy {


Could we infer this from the schema?

This one I haven't done it because we use different casing, and the dispatcher don't really care of every fields like createdAt, etc.. But maybe we'll revisit later, and just use the NotificationPolicyResponse as is.

cnasikas · 2026-02-27T16:16:36Z

x-pack/platform/plugins/shared/alerting_v2/server/setup/bind_services.ts

  );

  bind(RulesSavedObjectService).toSelf().inRequestScope();
+  bind(RulesSavedObjectServiceInternalToken)


Why would the NotificationPolicy SO service uses the Rules SO Service? This part is not clear to me.

Yes, sorry, it was a mistake by me. What I had in mind was something like this but feel free to ignore:

bind(InternalSavedObjectsClientFactory) .toResolvedValue( (savedObjects) => (includedHiddenTypes) => { const client = savedObjects.createInternalRepository(includedHiddenTypes); return () => client; }, [CoreStart('savedObjects')] ) .inSingletonScope(); bind(RulesSavedObjectService).toSelf().inRequestScope(); bind(RulesSavedObjectServiceScopedToken).toService(RulesSavedObjectService); bind(RulesSavedObjectServiceInternalToken) .toResolvedValue( (internalFactory, spaces) => new RulesSavedObjectService(internalFactory([RULE_SAVED_OBJECT_TYPE]), spaces), [ InternalSavedObjectsClientFactory, PluginStart<AlertingServerStartDependencies['spaces']>('spaces'), ] ) .inSingletonScope(); bind(NotificationPolicySavedObjectService).toSelf().inRequestScope(); bind(NotificationPolicySavedObjectServiceScopedToken).toService( NotificationPolicySavedObjectService ); bind(NotificationPolicySavedObjectServiceInternalToken) .toResolvedValue( (internalFactory, spaces) => new NotificationPolicySavedObjectService( internalFactory([NOTIFICATION_POLICY_SAVED_OBJECT_TYPE]), spaces ), [ InternalSavedObjectsClientFactory, PluginStart<AlertingServerStartDependencies['spaces']>('spaces'), ] ) .inSingletonScope();

elasticmachine · 2026-02-27T17:41:07Z

💔 Build Failed

Buildkite Build
Commit: f63d6f8

Failed CI Steps

Post-Build

Metrics [docs]

‼️ ERROR: no builds found for mergeBase sha [d8e74fb]

History

💔 Build #401777 failed 92e1a9d
💔 Build #401711 failed 01369e5
💚 Build #399396 succeeded a8f4287
💔 Build #399283 failed f6e255a
💔 Build #399242 failed f4eb7ba
💔 Build #398725 failed f1c1af1

cc @kdelemme

@cnasikas

## Summary ### Key capabilities - **ES|QL-native rule evaluation** — Rules are defined as ES|QL queries with optional WHERE clause conditions, evaluated on a configurable schedule - **Alert lifecycle management** — Full episode tracking with pending → active → recovering → inactive state transitions, including configurable alert delay (consecutive breaches / duration) - **Event-driven architecture** — Alert events and actions are stored in dedicated data streams (`.alerting-events`, `.alerting-actions`) with ES|QL views for querying - **Notification dispatch pipeline** — A multi-step dispatcher that matches alert episodes to notification policies, handles throttling/suppression, and triggers Kibana Workflows using encrypted API keys - **Notification policies** — CRUD APIs and UI for creating notification policies with KQL-based rule matching, workflow integration, and API key management - **Rule authoring UI** — A shared rule form package (`@kbn/alerting-v2-rule-form`) usable standalone or embedded in Discover, with ES|QL editor, WHERE clause condition editing, recovery configuration, and live query preview - **Rule management UI** — Full rule list with pagination, enable/disable, clone, edit, and delete operations - **APM instrumentation** — Middleware and decorators for tracing rule execution and client operations ### Architecture highlights - **InversifyJS DI** — All services use constructor injection with typed tokens, scoped per-request or singleton as appropriate - **Pipeline pattern** — Rule executor and dispatcher use composable step-based pipelines - **Saved Objects** — Rules stored as hidden saved objects; notification policies stored as encrypted saved objects (for API key protection) - **Feature privileges** — Dedicated Kibana feature with read/all privileges for RBAC --- ## Contained PRs <details> <summary>Core Engine & Plugin Init (12 PRs)</summary> - #247283 — Init alerting v2 plugin (@cnasikas) - #247452 — Add the alerting v2 feature privileges (@cnasikas) - #247673 — Director (@cnasikas) - #248306 — Create basic services (@cnasikas) - #248696 — Initialize all resources (@cnasikas) - #250023 — Schema package (@cnasikas) - #250010 — YML Editor (@cnasikas) - #251064 — Remove index.mode: lookup for RnA alert indices (@cnasikas) - #251707 — Simplify task registration pattern (@kdelemme) - #251876 — Dedicated user service (@cnasikas) - #252073 — Use `kbn/data-streams` in alerting_v2 (@cnasikas) - #255120 — Update alerting-v2 owner to new rna project team (@cnasikas) </details> <details> <summary>Rule Execution Pipeline (12 PRs)</summary> - #247472 — Add alerting v2 Rule Executor (@darnautov) - #248285 — Alerting v2 rule HTTP APIs (@darnautov) - #248728 — Add basic alert actions route (@darnautov) - #250161 — Refactor rule executor to use a pipeline pattern (@darnautov) - #252292 — Implement the CountTimeframeStrategy for the director (@cnasikas) - #252544 — Add support of streaming in the rule executor (@darnautov) - #252754 — Update rule attributes (@kdelemme) - #253355 — Add getRules client method (@kdelemme) - #253668 — Make evaluation.query.condition optional (@kdelemme) - #254031 — Add recovery event generation to rule execution pipeline (@kdelemme) - #255968 — ES|QL views (@adcoelho) - #256697 — Create episodes ES|QL view (@adcoelho) </details> <details> <summary>Alert Suppression & Episodes (3 PRs)</summary> - #252174 — Alert suppression (@kdelemme) - #256486 — Fix suppression query (@kdelemme) - #256527 — Store 'unmatched' action for unmatched alert episodes (@kdelemme) </details> <details> <summary>Dispatcher & Notification Engine (6 PRs)</summary> - #250822 — Alerting v2 dispatcher (@kdelemme) - #251529 — Use query service in dispatcher (@kdelemme) - #251679 — Dispatcher task (@kdelemme) - #252758 — Dispatcher notification policy (@kdelemme) - #255332 — Wait for resources before scheduling dispatcher task (@kdelemme) - #256536 — Use stored encrypted API keys from Notification Policy in dispatcher step (@kdelemme) </details> <details> <summary>Notification Policies (Server) (4 PRs)</summary> - #251336 — Introduce notification policy CRUD APIs and client (@cnasikas) - #253134 — Update notification policy (@cnasikas) - #254808 — Store API key owner on Notification Policy (@kdelemme) - #256940 — Make notification policies global with optional rule-label scoping (@kdelemme) </details> <details> <summary>Notification Policies UI (1 PR)</summary> - #255599 — Add notification policies UI and Storybook form story (@adcoelho) </details> <details> <summary>Rule Authoring UI (13 PRs)</summary> - #250961 — Add create rule flyout in Discover (@adcoelho) - #255111 — Add activation configuration fields to alerting V2 rule form (@yiannisnikolopoulos) - #255427 — Rule form: provide services via context (@dominiqueclarke) - #255876 — MVP rule form, Split evaluation condition, and Recovery configuration (@dominiqueclarke) - #256260 — Foundational rule list (@dominiqueclarke) - #256756 — Wire up edit flow (@dominiqueclarke) - #256801 — Move consecutive breaches max to shared constants (@yiannisnikolopoulos) - #256818 — Preview query and design parity (@dominiqueclarke) - #256938 — Allow clearing number inputs in state transition fields (@yiannisnikolopoulos) - #257017 — Add enable/disable and clone rule to rule list (@dominiqueclarke) - #257246 — Remove all React.FC (@dominiqueclarke) - #257415 — Rule form - fix test (@dominiqueclarke) - #257454 — Block comma key in number input component (@yiannisnikolopoulos) </details> <details> <summary>API Documentation & Schema (2 PRs)</summary> - #254901 — Rename indexes for alert events and actions (@adcoelho) - #255810 — OAS for alert action routes (@adcoelho) </details> <details> <summary>Observability & Monitoring (3 PRs)</summary> - #254925 — Add ApmMiddleware to the rule executor (@adcoelho) - #255115 — Add the withAPM decorator and apply it to the rules_client (@adcoelho) - #255999 — Fix linting problem in apm middleware (@adcoelho) </details> <details> <summary>CI & Maintenance (2 PRs)</summary> - #257409 — Refactor SO services to use inversify DI for client initialization (@darnautov) - Fix alerting-v2-schema jest config (@darnautov) </details> --- --------- Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kevin Delemme <kevin.delemme@elastic.co> Co-authored-by: Mike Côté <mikecote@users.noreply.github.com> Co-authored-by: Antonio <antonio.coelho@elastic.co> Co-authored-by: Kevin Delemme <kdelemme@gmail.com> Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co> Co-authored-by: Yiannis Nikolopoulos <yiannis.nikolopoulos@elastic.co> Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Bailey Cash <bailey.cash@elastic.co> Co-authored-by: Anna Davydova <ana.davydova@elastic.co> Co-authored-by: Umberto Pepato <umbopepato@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.matthew.rhodes@gmail.com> Co-authored-by: Joana Cardoso <169058851+joana-cps@users.noreply.github.com>

@cnasikas

## Summary ### Key capabilities - **ES|QL-native rule evaluation** — Rules are defined as ES|QL queries with optional WHERE clause conditions, evaluated on a configurable schedule - **Alert lifecycle management** — Full episode tracking with pending → active → recovering → inactive state transitions, including configurable alert delay (consecutive breaches / duration) - **Event-driven architecture** — Alert events and actions are stored in dedicated data streams (`.alerting-events`, `.alerting-actions`) with ES|QL views for querying - **Notification dispatch pipeline** — A multi-step dispatcher that matches alert episodes to notification policies, handles throttling/suppression, and triggers Kibana Workflows using encrypted API keys - **Notification policies** — CRUD APIs and UI for creating notification policies with KQL-based rule matching, workflow integration, and API key management - **Rule authoring UI** — A shared rule form package (`@kbn/alerting-v2-rule-form`) usable standalone or embedded in Discover, with ES|QL editor, WHERE clause condition editing, recovery configuration, and live query preview - **Rule management UI** — Full rule list with pagination, enable/disable, clone, edit, and delete operations - **APM instrumentation** — Middleware and decorators for tracing rule execution and client operations ### Architecture highlights - **InversifyJS DI** — All services use constructor injection with typed tokens, scoped per-request or singleton as appropriate - **Pipeline pattern** — Rule executor and dispatcher use composable step-based pipelines - **Saved Objects** — Rules stored as hidden saved objects; notification policies stored as encrypted saved objects (for API key protection) - **Feature privileges** — Dedicated Kibana feature with read/all privileges for RBAC --- ## Contained PRs <details> <summary>Core Engine & Plugin Init (12 PRs)</summary> - elastic#247283 — Init alerting v2 plugin (@cnasikas) - elastic#247452 — Add the alerting v2 feature privileges (@cnasikas) - elastic#247673 — Director (@cnasikas) - elastic#248306 — Create basic services (@cnasikas) - elastic#248696 — Initialize all resources (@cnasikas) - elastic#250023 — Schema package (@cnasikas) - elastic#250010 — YML Editor (@cnasikas) - elastic#251064 — Remove index.mode: lookup for RnA alert indices (@cnasikas) - elastic#251707 — Simplify task registration pattern (@kdelemme) - elastic#251876 — Dedicated user service (@cnasikas) - elastic#252073 — Use `kbn/data-streams` in alerting_v2 (@cnasikas) - elastic#255120 — Update alerting-v2 owner to new rna project team (@cnasikas) </details> <details> <summary>Rule Execution Pipeline (12 PRs)</summary> - elastic#247472 — Add alerting v2 Rule Executor (@darnautov) - elastic#248285 — Alerting v2 rule HTTP APIs (@darnautov) - elastic#248728 — Add basic alert actions route (@darnautov) - elastic#250161 — Refactor rule executor to use a pipeline pattern (@darnautov) - elastic#252292 — Implement the CountTimeframeStrategy for the director (@cnasikas) - elastic#252544 — Add support of streaming in the rule executor (@darnautov) - elastic#252754 — Update rule attributes (@kdelemme) - elastic#253355 — Add getRules client method (@kdelemme) - elastic#253668 — Make evaluation.query.condition optional (@kdelemme) - elastic#254031 — Add recovery event generation to rule execution pipeline (@kdelemme) - elastic#255968 — ES&elastic#124;QL views (@adcoelho) - elastic#256697 — Create episodes ES&elastic#124;QL view (@adcoelho) </details> <details> <summary>Alert Suppression & Episodes (3 PRs)</summary> - elastic#252174 — Alert suppression (@kdelemme) - elastic#256486 — Fix suppression query (@kdelemme) - elastic#256527 — Store 'unmatched' action for unmatched alert episodes (@kdelemme) </details> <details> <summary>Dispatcher & Notification Engine (6 PRs)</summary> - elastic#250822 — Alerting v2 dispatcher (@kdelemme) - elastic#251529 — Use query service in dispatcher (@kdelemme) - elastic#251679 — Dispatcher task (@kdelemme) - elastic#252758 — Dispatcher notification policy (@kdelemme) - elastic#255332 — Wait for resources before scheduling dispatcher task (@kdelemme) - elastic#256536 — Use stored encrypted API keys from Notification Policy in dispatcher step (@kdelemme) </details> <details> <summary>Notification Policies (Server) (4 PRs)</summary> - elastic#251336 — Introduce notification policy CRUD APIs and client (@cnasikas) - elastic#253134 — Update notification policy (@cnasikas) - elastic#254808 — Store API key owner on Notification Policy (@kdelemme) - elastic#256940 — Make notification policies global with optional rule-label scoping (@kdelemme) </details> <details> <summary>Notification Policies UI (1 PR)</summary> - elastic#255599 — Add notification policies UI and Storybook form story (@adcoelho) </details> <details> <summary>Rule Authoring UI (13 PRs)</summary> - elastic#250961 — Add create rule flyout in Discover (@adcoelho) - elastic#255111 — Add activation configuration fields to alerting V2 rule form (@yiannisnikolopoulos) - elastic#255427 — Rule form: provide services via context (@dominiqueclarke) - elastic#255876 — MVP rule form, Split evaluation condition, and Recovery configuration (@dominiqueclarke) - elastic#256260 — Foundational rule list (@dominiqueclarke) - elastic#256756 — Wire up edit flow (@dominiqueclarke) - elastic#256801 — Move consecutive breaches max to shared constants (@yiannisnikolopoulos) - elastic#256818 — Preview query and design parity (@dominiqueclarke) - elastic#256938 — Allow clearing number inputs in state transition fields (@yiannisnikolopoulos) - elastic#257017 — Add enable/disable and clone rule to rule list (@dominiqueclarke) - elastic#257246 — Remove all React.FC (@dominiqueclarke) - elastic#257415 — Rule form - fix test (@dominiqueclarke) - elastic#257454 — Block comma key in number input component (@yiannisnikolopoulos) </details> <details> <summary>API Documentation & Schema (2 PRs)</summary> - elastic#254901 — Rename indexes for alert events and actions (@adcoelho) - elastic#255810 — OAS for alert action routes (@adcoelho) </details> <details> <summary>Observability & Monitoring (3 PRs)</summary> - elastic#254925 — Add ApmMiddleware to the rule executor (@adcoelho) - elastic#255115 — Add the withAPM decorator and apply it to the rules_client (@adcoelho) - elastic#255999 — Fix linting problem in apm middleware (@adcoelho) </details> <details> <summary>CI & Maintenance (2 PRs)</summary> - elastic#257409 — Refactor SO services to use inversify DI for client initialization (@darnautov) - Fix alerting-v2-schema jest config (@darnautov) </details> --- --------- Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kevin Delemme <kevin.delemme@elastic.co> Co-authored-by: Mike Côté <mikecote@users.noreply.github.com> Co-authored-by: Antonio <antonio.coelho@elastic.co> Co-authored-by: Kevin Delemme <kdelemme@gmail.com> Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co> Co-authored-by: Yiannis Nikolopoulos <yiannis.nikolopoulos@elastic.co> Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Bailey Cash <bailey.cash@elastic.co> Co-authored-by: Anna Davydova <ana.davydova@elastic.co> Co-authored-by: Umberto Pepato <umbopepato@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.matthew.rhodes@gmail.com> Co-authored-by: Joana Cardoso <169058851+joana-cps@users.noreply.github.com>

@cnasikas

- **ES|QL-native rule evaluation** — Rules are defined as ES|QL queries with optional WHERE clause conditions, evaluated on a configurable schedule - **Alert lifecycle management** — Full episode tracking with pending → active → recovering → inactive state transitions, including configurable alert delay (consecutive breaches / duration) - **Event-driven architecture** — Alert events and actions are stored in dedicated data streams (`.alerting-events`, `.alerting-actions`) with ES|QL views for querying - **Notification dispatch pipeline** — A multi-step dispatcher that matches alert episodes to notification policies, handles throttling/suppression, and triggers Kibana Workflows using encrypted API keys - **Notification policies** — CRUD APIs and UI for creating notification policies with KQL-based rule matching, workflow integration, and API key management - **Rule authoring UI** — A shared rule form package (`@kbn/alerting-v2-rule-form`) usable standalone or embedded in Discover, with ES|QL editor, WHERE clause condition editing, recovery configuration, and live query preview - **Rule management UI** — Full rule list with pagination, enable/disable, clone, edit, and delete operations - **APM instrumentation** — Middleware and decorators for tracing rule execution and client operations - **InversifyJS DI** — All services use constructor injection with typed tokens, scoped per-request or singleton as appropriate - **Pipeline pattern** — Rule executor and dispatcher use composable step-based pipelines - **Saved Objects** — Rules stored as hidden saved objects; notification policies stored as encrypted saved objects (for API key protection) - **Feature privileges** — Dedicated Kibana feature with read/all privileges for RBAC --- <details> <summary>Core Engine & Plugin Init (12 PRs)</summary> - elastic#247283 — Init alerting v2 plugin (@cnasikas) - elastic#247452 — Add the alerting v2 feature privileges (@cnasikas) - elastic#247673 — Director (@cnasikas) - elastic#248306 — Create basic services (@cnasikas) - elastic#248696 — Initialize all resources (@cnasikas) - elastic#250023 — Schema package (@cnasikas) - elastic#250010 — YML Editor (@cnasikas) - elastic#251064 — Remove index.mode: lookup for RnA alert indices (@cnasikas) - elastic#251707 — Simplify task registration pattern (@kdelemme) - elastic#251876 — Dedicated user service (@cnasikas) - elastic#252073 — Use `kbn/data-streams` in alerting_v2 (@cnasikas) - elastic#255120 — Update alerting-v2 owner to new rna project team (@cnasikas) </details> <details> <summary>Rule Execution Pipeline (12 PRs)</summary> - elastic#247472 — Add alerting v2 Rule Executor (@darnautov) - elastic#248285 — Alerting v2 rule HTTP APIs (@darnautov) - elastic#248728 — Add basic alert actions route (@darnautov) - elastic#250161 — Refactor rule executor to use a pipeline pattern (@darnautov) - elastic#252292 — Implement the CountTimeframeStrategy for the director (@cnasikas) - elastic#252544 — Add support of streaming in the rule executor (@darnautov) - elastic#252754 — Update rule attributes (@kdelemme) - elastic#253355 — Add getRules client method (@kdelemme) - elastic#253668 — Make evaluation.query.condition optional (@kdelemme) - elastic#254031 — Add recovery event generation to rule execution pipeline (@kdelemme) - elastic#255968 — ES&elastic#124;QL views (@adcoelho) - elastic#256697 — Create episodes ES&elastic#124;QL view (@adcoelho) </details> <details> <summary>Alert Suppression & Episodes (3 PRs)</summary> - elastic#252174 — Alert suppression (@kdelemme) - elastic#256486 — Fix suppression query (@kdelemme) - elastic#256527 — Store 'unmatched' action for unmatched alert episodes (@kdelemme) </details> <details> <summary>Dispatcher & Notification Engine (6 PRs)</summary> - elastic#250822 — Alerting v2 dispatcher (@kdelemme) - elastic#251529 — Use query service in dispatcher (@kdelemme) - elastic#251679 — Dispatcher task (@kdelemme) - elastic#252758 — Dispatcher notification policy (@kdelemme) - elastic#255332 — Wait for resources before scheduling dispatcher task (@kdelemme) - elastic#256536 — Use stored encrypted API keys from Notification Policy in dispatcher step (@kdelemme) </details> <details> <summary>Notification Policies (Server) (4 PRs)</summary> - elastic#251336 — Introduce notification policy CRUD APIs and client (@cnasikas) - elastic#253134 — Update notification policy (@cnasikas) - elastic#254808 — Store API key owner on Notification Policy (@kdelemme) - elastic#256940 — Make notification policies global with optional rule-label scoping (@kdelemme) </details> <details> <summary>Notification Policies UI (1 PR)</summary> - elastic#255599 — Add notification policies UI and Storybook form story (@adcoelho) </details> <details> <summary>Rule Authoring UI (13 PRs)</summary> - elastic#250961 — Add create rule flyout in Discover (@adcoelho) - elastic#255111 — Add activation configuration fields to alerting V2 rule form (@yiannisnikolopoulos) - elastic#255427 — Rule form: provide services via context (@dominiqueclarke) - elastic#255876 — MVP rule form, Split evaluation condition, and Recovery configuration (@dominiqueclarke) - elastic#256260 — Foundational rule list (@dominiqueclarke) - elastic#256756 — Wire up edit flow (@dominiqueclarke) - elastic#256801 — Move consecutive breaches max to shared constants (@yiannisnikolopoulos) - elastic#256818 — Preview query and design parity (@dominiqueclarke) - elastic#256938 — Allow clearing number inputs in state transition fields (@yiannisnikolopoulos) - elastic#257017 — Add enable/disable and clone rule to rule list (@dominiqueclarke) - elastic#257246 — Remove all React.FC (@dominiqueclarke) - elastic#257415 — Rule form - fix test (@dominiqueclarke) - elastic#257454 — Block comma key in number input component (@yiannisnikolopoulos) </details> <details> <summary>API Documentation & Schema (2 PRs)</summary> - elastic#254901 — Rename indexes for alert events and actions (@adcoelho) - elastic#255810 — OAS for alert action routes (@adcoelho) </details> <details> <summary>Observability & Monitoring (3 PRs)</summary> - elastic#254925 — Add ApmMiddleware to the rule executor (@adcoelho) - elastic#255115 — Add the withAPM decorator and apply it to the rules_client (@adcoelho) - elastic#255999 — Fix linting problem in apm middleware (@adcoelho) </details> <details> <summary>CI & Maintenance (2 PRs)</summary> - elastic#257409 — Refactor SO services to use inversify DI for client initialization (@darnautov) - Fix alerting-v2-schema jest config (@darnautov) </details> --- --------- Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kevin Delemme <kevin.delemme@elastic.co> Co-authored-by: Mike Côté <mikecote@users.noreply.github.com> Co-authored-by: Antonio <antonio.coelho@elastic.co> Co-authored-by: Kevin Delemme <kdelemme@gmail.com> Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co> Co-authored-by: Yiannis Nikolopoulos <yiannis.nikolopoulos@elastic.co> Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Bailey Cash <bailey.cash@elastic.co> Co-authored-by: Anna Davydova <ana.davydova@elastic.co> Co-authored-by: Umberto Pepato <umbopepato@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.matthew.rhodes@gmail.com> Co-authored-by: Joana Cardoso <169058851+joana-cps@users.noreply.github.com>

@cnasikas

- **ES|QL-native rule evaluation** — Rules are defined as ES|QL queries with optional WHERE clause conditions, evaluated on a configurable schedule - **Alert lifecycle management** — Full episode tracking with pending → active → recovering → inactive state transitions, including configurable alert delay (consecutive breaches / duration) - **Event-driven architecture** — Alert events and actions are stored in dedicated data streams (`.alerting-events`, `.alerting-actions`) with ES|QL views for querying - **Notification dispatch pipeline** — A multi-step dispatcher that matches alert episodes to notification policies, handles throttling/suppression, and triggers Kibana Workflows using encrypted API keys - **Notification policies** — CRUD APIs and UI for creating notification policies with KQL-based rule matching, workflow integration, and API key management - **Rule authoring UI** — A shared rule form package (`@kbn/alerting-v2-rule-form`) usable standalone or embedded in Discover, with ES|QL editor, WHERE clause condition editing, recovery configuration, and live query preview - **Rule management UI** — Full rule list with pagination, enable/disable, clone, edit, and delete operations - **APM instrumentation** — Middleware and decorators for tracing rule execution and client operations - **InversifyJS DI** — All services use constructor injection with typed tokens, scoped per-request or singleton as appropriate - **Pipeline pattern** — Rule executor and dispatcher use composable step-based pipelines - **Saved Objects** — Rules stored as hidden saved objects; notification policies stored as encrypted saved objects (for API key protection) - **Feature privileges** — Dedicated Kibana feature with read/all privileges for RBAC --- <details> <summary>Core Engine & Plugin Init (12 PRs)</summary> - elastic#247283 — Init alerting v2 plugin (@cnasikas) - elastic#247452 — Add the alerting v2 feature privileges (@cnasikas) - elastic#247673 — Director (@cnasikas) - elastic#248306 — Create basic services (@cnasikas) - elastic#248696 — Initialize all resources (@cnasikas) - elastic#250023 — Schema package (@cnasikas) - elastic#250010 — YML Editor (@cnasikas) - elastic#251064 — Remove index.mode: lookup for RnA alert indices (@cnasikas) - elastic#251707 — Simplify task registration pattern (@kdelemme) - elastic#251876 — Dedicated user service (@cnasikas) - elastic#252073 — Use `kbn/data-streams` in alerting_v2 (@cnasikas) - elastic#255120 — Update alerting-v2 owner to new rna project team (@cnasikas) </details> <details> <summary>Rule Execution Pipeline (12 PRs)</summary> - elastic#247472 — Add alerting v2 Rule Executor (@darnautov) - elastic#248285 — Alerting v2 rule HTTP APIs (@darnautov) - elastic#248728 — Add basic alert actions route (@darnautov) - elastic#250161 — Refactor rule executor to use a pipeline pattern (@darnautov) - elastic#252292 — Implement the CountTimeframeStrategy for the director (@cnasikas) - elastic#252544 — Add support of streaming in the rule executor (@darnautov) - elastic#252754 — Update rule attributes (@kdelemme) - elastic#253355 — Add getRules client method (@kdelemme) - elastic#253668 — Make evaluation.query.condition optional (@kdelemme) - elastic#254031 — Add recovery event generation to rule execution pipeline (@kdelemme) - elastic#255968 — ES&elastic#124;QL views (@adcoelho) - elastic#256697 — Create episodes ES&elastic#124;QL view (@adcoelho) </details> <details> <summary>Alert Suppression & Episodes (3 PRs)</summary> - elastic#252174 — Alert suppression (@kdelemme) - elastic#256486 — Fix suppression query (@kdelemme) - elastic#256527 — Store 'unmatched' action for unmatched alert episodes (@kdelemme) </details> <details> <summary>Dispatcher & Notification Engine (6 PRs)</summary> - elastic#250822 — Alerting v2 dispatcher (@kdelemme) - elastic#251529 — Use query service in dispatcher (@kdelemme) - elastic#251679 — Dispatcher task (@kdelemme) - elastic#252758 — Dispatcher notification policy (@kdelemme) - elastic#255332 — Wait for resources before scheduling dispatcher task (@kdelemme) - elastic#256536 — Use stored encrypted API keys from Notification Policy in dispatcher step (@kdelemme) </details> <details> <summary>Notification Policies (Server) (4 PRs)</summary> - elastic#251336 — Introduce notification policy CRUD APIs and client (@cnasikas) - elastic#253134 — Update notification policy (@cnasikas) - elastic#254808 — Store API key owner on Notification Policy (@kdelemme) - elastic#256940 — Make notification policies global with optional rule-label scoping (@kdelemme) </details> <details> <summary>Notification Policies UI (1 PR)</summary> - elastic#255599 — Add notification policies UI and Storybook form story (@adcoelho) </details> <details> <summary>Rule Authoring UI (13 PRs)</summary> - elastic#250961 — Add create rule flyout in Discover (@adcoelho) - elastic#255111 — Add activation configuration fields to alerting V2 rule form (@yiannisnikolopoulos) - elastic#255427 — Rule form: provide services via context (@dominiqueclarke) - elastic#255876 — MVP rule form, Split evaluation condition, and Recovery configuration (@dominiqueclarke) - elastic#256260 — Foundational rule list (@dominiqueclarke) - elastic#256756 — Wire up edit flow (@dominiqueclarke) - elastic#256801 — Move consecutive breaches max to shared constants (@yiannisnikolopoulos) - elastic#256818 — Preview query and design parity (@dominiqueclarke) - elastic#256938 — Allow clearing number inputs in state transition fields (@yiannisnikolopoulos) - elastic#257017 — Add enable/disable and clone rule to rule list (@dominiqueclarke) - elastic#257246 — Remove all React.FC (@dominiqueclarke) - elastic#257415 — Rule form - fix test (@dominiqueclarke) - elastic#257454 — Block comma key in number input component (@yiannisnikolopoulos) </details> <details> <summary>API Documentation & Schema (2 PRs)</summary> - elastic#254901 — Rename indexes for alert events and actions (@adcoelho) - elastic#255810 — OAS for alert action routes (@adcoelho) </details> <details> <summary>Observability & Monitoring (3 PRs)</summary> - elastic#254925 — Add ApmMiddleware to the rule executor (@adcoelho) - elastic#255115 — Add the withAPM decorator and apply it to the rules_client (@adcoelho) - elastic#255999 — Fix linting problem in apm middleware (@adcoelho) </details> <details> <summary>CI & Maintenance (2 PRs)</summary> - elastic#257409 — Refactor SO services to use inversify DI for client initialization (@darnautov) - Fix alerting-v2-schema jest config (@darnautov) </details> --- --------- Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kevin Delemme <kevin.delemme@elastic.co> Co-authored-by: Mike Côté <mikecote@users.noreply.github.com> Co-authored-by: Antonio <antonio.coelho@elastic.co> Co-authored-by: Kevin Delemme <kdelemme@gmail.com> Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co> Co-authored-by: Yiannis Nikolopoulos <yiannis.nikolopoulos@elastic.co> Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Bailey Cash <bailey.cash@elastic.co> Co-authored-by: Anna Davydova <ana.davydova@elastic.co> Co-authored-by: Umberto Pepato <umbopepato@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.matthew.rhodes@gmail.com> Co-authored-by: Joana Cardoso <169058851+joana-cps@users.noreply.github.com>

@cnasikas

## Summary ### Key capabilities - **ES|QL-native rule evaluation** — Rules are defined as ES|QL queries with optional WHERE clause conditions, evaluated on a configurable schedule - **Alert lifecycle management** — Full episode tracking with pending → active → recovering → inactive state transitions, including configurable alert delay (consecutive breaches / duration) - **Event-driven architecture** — Alert events and actions are stored in dedicated data streams (`.alerting-events`, `.alerting-actions`) with ES|QL views for querying - **Notification dispatch pipeline** — A multi-step dispatcher that matches alert episodes to notification policies, handles throttling/suppression, and triggers Kibana Workflows using encrypted API keys - **Notification policies** — CRUD APIs and UI for creating notification policies with KQL-based rule matching, workflow integration, and API key management - **Rule authoring UI** — A shared rule form package (`@kbn/alerting-v2-rule-form`) usable standalone or embedded in Discover, with ES|QL editor, WHERE clause condition editing, recovery configuration, and live query preview - **Rule management UI** — Full rule list with pagination, enable/disable, clone, edit, and delete operations - **APM instrumentation** — Middleware and decorators for tracing rule execution and client operations ### Architecture highlights - **InversifyJS DI** — All services use constructor injection with typed tokens, scoped per-request or singleton as appropriate - **Pipeline pattern** — Rule executor and dispatcher use composable step-based pipelines - **Saved Objects** — Rules stored as hidden saved objects; notification policies stored as encrypted saved objects (for API key protection) - **Feature privileges** — Dedicated Kibana feature with read/all privileges for RBAC --- ## Contained PRs <details> <summary>Core Engine & Plugin Init (12 PRs)</summary> - elastic#247283 — Init alerting v2 plugin (@cnasikas) - elastic#247452 — Add the alerting v2 feature privileges (@cnasikas) - elastic#247673 — Director (@cnasikas) - elastic#248306 — Create basic services (@cnasikas) - elastic#248696 — Initialize all resources (@cnasikas) - elastic#250023 — Schema package (@cnasikas) - elastic#250010 — YML Editor (@cnasikas) - elastic#251064 — Remove index.mode: lookup for RnA alert indices (@cnasikas) - elastic#251707 — Simplify task registration pattern (@kdelemme) - elastic#251876 — Dedicated user service (@cnasikas) - elastic#252073 — Use `kbn/data-streams` in alerting_v2 (@cnasikas) - elastic#255120 — Update alerting-v2 owner to new rna project team (@cnasikas) </details> <details> <summary>Rule Execution Pipeline (12 PRs)</summary> - elastic#247472 — Add alerting v2 Rule Executor (@darnautov) - elastic#248285 — Alerting v2 rule HTTP APIs (@darnautov) - elastic#248728 — Add basic alert actions route (@darnautov) - elastic#250161 — Refactor rule executor to use a pipeline pattern (@darnautov) - elastic#252292 — Implement the CountTimeframeStrategy for the director (@cnasikas) - elastic#252544 — Add support of streaming in the rule executor (@darnautov) - elastic#252754 — Update rule attributes (@kdelemme) - elastic#253355 — Add getRules client method (@kdelemme) - elastic#253668 — Make evaluation.query.condition optional (@kdelemme) - elastic#254031 — Add recovery event generation to rule execution pipeline (@kdelemme) - elastic#255968 — ES&elastic#124;QL views (@adcoelho) - elastic#256697 — Create episodes ES&elastic#124;QL view (@adcoelho) </details> <details> <summary>Alert Suppression & Episodes (3 PRs)</summary> - elastic#252174 — Alert suppression (@kdelemme) - elastic#256486 — Fix suppression query (@kdelemme) - elastic#256527 — Store 'unmatched' action for unmatched alert episodes (@kdelemme) </details> <details> <summary>Dispatcher & Notification Engine (6 PRs)</summary> - elastic#250822 — Alerting v2 dispatcher (@kdelemme) - elastic#251529 — Use query service in dispatcher (@kdelemme) - elastic#251679 — Dispatcher task (@kdelemme) - elastic#252758 — Dispatcher notification policy (@kdelemme) - elastic#255332 — Wait for resources before scheduling dispatcher task (@kdelemme) - elastic#256536 — Use stored encrypted API keys from Notification Policy in dispatcher step (@kdelemme) </details> <details> <summary>Notification Policies (Server) (4 PRs)</summary> - elastic#251336 — Introduce notification policy CRUD APIs and client (@cnasikas) - elastic#253134 — Update notification policy (@cnasikas) - elastic#254808 — Store API key owner on Notification Policy (@kdelemme) - elastic#256940 — Make notification policies global with optional rule-label scoping (@kdelemme) </details> <details> <summary>Notification Policies UI (1 PR)</summary> - elastic#255599 — Add notification policies UI and Storybook form story (@adcoelho) </details> <details> <summary>Rule Authoring UI (13 PRs)</summary> - elastic#250961 — Add create rule flyout in Discover (@adcoelho) - elastic#255111 — Add activation configuration fields to alerting V2 rule form (@yiannisnikolopoulos) - elastic#255427 — Rule form: provide services via context (@dominiqueclarke) - elastic#255876 — MVP rule form, Split evaluation condition, and Recovery configuration (@dominiqueclarke) - elastic#256260 — Foundational rule list (@dominiqueclarke) - elastic#256756 — Wire up edit flow (@dominiqueclarke) - elastic#256801 — Move consecutive breaches max to shared constants (@yiannisnikolopoulos) - elastic#256818 — Preview query and design parity (@dominiqueclarke) - elastic#256938 — Allow clearing number inputs in state transition fields (@yiannisnikolopoulos) - elastic#257017 — Add enable/disable and clone rule to rule list (@dominiqueclarke) - elastic#257246 — Remove all React.FC (@dominiqueclarke) - elastic#257415 — Rule form - fix test (@dominiqueclarke) - elastic#257454 — Block comma key in number input component (@yiannisnikolopoulos) </details> <details> <summary>API Documentation & Schema (2 PRs)</summary> - elastic#254901 — Rename indexes for alert events and actions (@adcoelho) - elastic#255810 — OAS for alert action routes (@adcoelho) </details> <details> <summary>Observability & Monitoring (3 PRs)</summary> - elastic#254925 — Add ApmMiddleware to the rule executor (@adcoelho) - elastic#255115 — Add the withAPM decorator and apply it to the rules_client (@adcoelho) - elastic#255999 — Fix linting problem in apm middleware (@adcoelho) </details> <details> <summary>CI & Maintenance (2 PRs)</summary> - elastic#257409 — Refactor SO services to use inversify DI for client initialization (@darnautov) - Fix alerting-v2-schema jest config (@darnautov) </details> --- --------- Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kevin Delemme <kevin.delemme@elastic.co> Co-authored-by: Mike Côté <mikecote@users.noreply.github.com> Co-authored-by: Antonio <antonio.coelho@elastic.co> Co-authored-by: Kevin Delemme <kdelemme@gmail.com> Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co> Co-authored-by: Yiannis Nikolopoulos <yiannis.nikolopoulos@elastic.co> Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Bailey Cash <bailey.cash@elastic.co> Co-authored-by: Anna Davydova <ana.davydova@elastic.co> Co-authored-by: Umberto Pepato <umbopepato@users.noreply.github.com> Co-authored-by: Jason Rhodes <jason.matthew.rhodes@gmail.com> Co-authored-by: Joana Cardoso <169058851+joana-cps@users.noreply.github.com>

kdelemme added 29 commits February 5, 2026 09:57

Fix wiring

246ef0b

Fix bulk query after schema change

1ee1620

Fix bulk query after schema change

770fafe

wip

3069894

add agent

9ce04f7

Suppress alert

d8cf2bb

Add apm span

a154115

use partition

2216998

debug log

fd6c77b

Update agent docs

72e7c75

Update tests

933adba

Add comprehensive test scenario

01c86fa

Remove llm docs

b3ecb51

Fix dispatcher

5f7099c

Add integration tests

7d41c1d

Merge branch 'alerting_v2' into alertingv2/dispatcher-suppression

48b971b

Merge branch 'alerting_v2' into alertingv2/dispatcher-suppression

2815d8e

Improve suppression algo

9eba0ea

Merge branch 'alerting_v2' into alertingv2/dispatcher-suppression

ec2ae3d

remove import

fd4fbd0

provide actionType

b3570f3

Update mocks

7878155

POC notificationm policy

bbc6fc0

poc

0b24ee5

make matcher optional

3187391

Add reason of suppression

3a276be

Add reason for notified group action

e04bc72

Fix throttling

93c64bb

Return early

bf95941

github-actions bot added the author:actionable-obs PRs authored by the actionable obs team label Feb 11, 2026

kdelemme added 2 commits February 23, 2026 07:50

Remove workflow and apikey in notificaiton policy for now

34b2e23

Merge branch 'alerting_v2' into alertingv2/poc-dispatcher-notificatio…

f4eb7ba

…n-policy

Changes from node scripts/lint_ts_projects --fix

f6e255a

Update integration tests

a8f4287

kdelemme marked this pull request as ready for review February 23, 2026 16:32

kdelemme requested a review from a team as a code owner February 23, 2026 16:32

cnasikas changed the title ~~poc(rna): dispatcher notification policy~~ Alerting_v2: Dispatcher notification policy Feb 26, 2026

cnasikas reviewed Feb 26, 2026

View reviewed changes

kdelemme added 7 commits February 26, 2026 12:25

Merge branch 'alerting_v2' into alertingv2/poc-dispatcher-notificatio…

01369e5

…n-policy

Move to injectable()

43d8446

reuse test_util

d951a95

reuse mocks

aae8266

move tokens into their service folder

dd22e98

use correct token names

5702779

Remove raw function

92e1a9d

cnasikas approved these changes Feb 27, 2026

View reviewed changes

Address comments

f63d6f8

kdelemme merged commit 7a52b28 into elastic:alerting_v2 Feb 27, 2026
12 of 13 checks passed

kdelemme deleted the alertingv2/poc-dispatcher-notification-policy branch February 27, 2026 18:54

darnautov mentioned this pull request Mar 13, 2026

[ResponseOps][Alerting] Alerting v2 #247464

Merged

kdelemme mentioned this pull request Mar 23, 2026

feat(alertingv2): update list notification policies table #259114

Merged

Conversation

kdelemme commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Dispatcher and Notification Policy Architecture

Out of scope for this PR

Decision that can be revisited

Dispatcher pipeline

Step 1: Fetch alert episodes

Step 2: Fetch suppressions

Step 3: Apply suppressions

Step 4: Fetch rules

Step 5: Fetch notification policies

Step 6: Evaluate matchers

Step 7: Build notification groups

Step 8: Apply throttling

Step 9: Dispatch to workflows

Step 10: Record outcomes

Notification policy

Fields

Matcher evaluation

Grouping semantics

Throttle semantics

Outcome recording and .alerts-actions schema

action_type: "fire"

action_type: "suppress"

action_type: "notified"

Uh oh!

kdelemme commented Feb 23, 2026

Uh oh!

kdelemme commented Feb 23, 2026

Uh oh!

kdelemme commented Feb 23, 2026

Uh oh!

cnasikas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cnasikas Feb 26, 2026

Choose a reason for hiding this comment

Uh oh!

kdelemme Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kdelemme Feb 26, 2026

Choose a reason for hiding this comment

Uh oh!

cnasikas Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cnasikas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cnasikas Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

kdelemme Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

cnasikas Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Feb 27, 2026

💔 Build Failed

Failed CI Steps

Metrics [docs]

History

kdelemme commented Feb 11, 2026 •

edited

Loading

Outcome recording and `.alerts-actions` schema

kdelemme Feb 26, 2026 •

edited

Loading