Skip to content

Store API key owner on Notification Policy#254808

Merged
kdelemme merged 52 commits intoelastic:alerting_v2from
kdelemme:alertingv2/handle-api-key-notification-policy
Mar 4, 2026
Merged

Store API key owner on Notification Policy#254808
kdelemme merged 52 commits intoelastic:alerting_v2from
kdelemme:alertingv2/handle-api-key-notification-policy

Conversation

@kdelemme
Copy link
Copy Markdown
Contributor

@kdelemme kdelemme commented Feb 24, 2026

Summary

Adds API key support to the notification policy saved object, following the same ESO pattern as alerting v1 rules.

  • Stores ES API key (encrypted) OR UIAM API key on the notification policy SO
  • Stores owner and createdByUser as AAD fields
  • Creates/rotates API keys on policy create and update
  • Strips apiKey from all API responses
  • Adds encryptedSavedObjects plugin dependency

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

Out of scope

  • API key invalidation lifecycle (follow-up)
  • Dispatcher integration to use decrypted keys for workflow dispatch (follow-up, after dispatcher PR merges)

Made with Cursor

@github-actions github-actions bot added the author:actionable-obs PRs authored by the actionable obs team label Feb 24, 2026
@kdelemme kdelemme force-pushed the alertingv2/handle-api-key-notification-policy branch from 7719960 to 4f4287c Compare February 24, 2026 20:26
@kdelemme
Copy link
Copy Markdown
Contributor Author

/ci

@kdelemme kdelemme removed the request for review from a team February 27, 2026 20:05
@kdelemme kdelemme self-assigned this Mar 2, 2026
@jasonrhodes
Copy link
Copy Markdown
Member

I'm reviewing this now FWIW 🍿

Copy link
Copy Markdown
Member

@jasonrhodes jasonrhodes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did manual testing locally, ran against a CCS edge cluster with ESO encryption key configured (--xpack.encryptedSavedObjects.encryptionKey="abcdefghijklmnopqrstuvwxyz123456")

Auth method Code path apiKeyCreatedByUser
API key header Reuse (extracts from header) true
Session cookie Grant (grantAsInternalUser) false
Basic auth Grant (grantAsInternalUser) false

CRUD verified

  • Create with auto-generated and custom IDs work. apiKeyOwner and apiKeyCreatedByUser present in responses; apiKey and uiamApiKey correctly stripped
  • GET requests return cleanly, secrets absent
  • Update preserves unmodified fields, bumps version (optimistic concurrency working).
  • Delete works.

Key rotation confirmed (grant path)

Queried _security/_query/api_key filtering on metadata.kibana.type: notification_policy. After creating a policy via basic auth and then updating it, a new ES API key was created with the updated policy name — 3 keys total, confirming grantAsInternalUser is called on every update (no other way to confirm real rotation except by counting keys created). Old keys remain invalidated: false, consistent with the PR noting invalidation as a follow-up.

ESO encryption confirmed

Raw SO in .kibana_alerting_cases shows apiKey as encrypted ciphertext, uiamApiKey as null (non-serverless), and apiKeyOwner/apiKeyCreatedByUser as plaintext AAD fields.

Will approve PR after I finish reading through code.

Comment on lines +31 to +34
apiKey: schema.maybe(schema.string()),
uiamApiKey: schema.maybe(schema.nullable(schema.string())),
apiKeyOwner: schema.string(),
apiKeyCreatedByUser: schema.boolean(),
Copy link
Copy Markdown
Member

@jasonrhodes jasonrhodes Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please correct me if I'm off-base here, but is this schema shape mostly borrowed from v1 alerting? This "two optional sibling keys" situation stood out to me, neither is required, does that mean both can be stored? Why do we need both in v2 alerting?

Could a discriminated union work for v2 if we don't have backward-compatibility concerns on this front?

{
  auth: {
    key: schema.string(),
    type: schema.oneOf(['ES_API_KEY', 'UIAM_API_KEY']),
    owner: schema.string(),
    createdByUser: schema.boolean(),
  }
}
More context from my conversation with the agent on this idea...

...

Yes, both keys are actively stored today in v1, in one specific scenario: the grant path in serverless environments. This is not a legacy
artifact — it's current behavior.
Here's exactly what happens in each v1 code path:

Grant path (password/token auth)

In createAPIKey in rules_client_factory.ts:

  1. Check shouldGrantUiam (which is !!core.security.authc.apiKeys.uiam — true only when UIAM is available, i.e. serverless)
  2. If serverless: grant a UIAM key first, then grant an ES key. Store both on the SO.
  3. If non-serverless: grant only an ES key. uiamApiKey is not set.

Reuse path (API key auth)

In getAuthenticationAPIKey: the user's own key is extracted from the header. If it's a UIAM credential, it goes into uiamResult only (no result).
If it's a regular ES key, it goes into result only. The apiKeyAsAlertAttributes function then stores it in the appropriate field. Only one key
is stored.

Why does the grant path store both?

Because in v1, the write-time decision (which keys to create) and the read-time decision (which key to use) are controlled by two different
config flags:
• Write time: shouldGrantUiam — determined by whether the UIAM API is available at all
• Read time: context.apiKeyType — a separate kibana.yml config (xpack.alerting.rules.apiKeyType) that defaults to 'es' and can be set to 'uiam'

So in serverless, UIAM is available (so both keys get created), but the task runner might still be configured to use the ES key (apiKeyType:
'es'). The system stores both so that operators can flip apiKeyType from es to uiam without having to re-grant every rule's API key. The task
runner then picks whichever one the config says to use:

x-pack/platform/plugins/shared/alerting/server/task_runner/rule_loader.ts lines 161-171

const shouldUseUiamApiKey = context.shouldGrantUiam && context.apiKeyType === ApiKeyType.UIAM;
if (shouldUseUiamApiKey) {
  if (!uiamApiKey) {
    requestHeaders.authorization = `ApiKey ${apiKey}`;
    // ... fallback warning
  } else {
    // ... use uiamApiKey
  }
} else if (apiKey) {
  requestHeaders.authorization = `ApiKey ${apiKey}`;
}

So is this relevant to v2?

The reason v1 needs both is that there are potentially millions of existing rules, and rotating keys on all of them just because an operator
flipped a config flag is operationally expensive. Storing both is a pragmatic optimization to avoid mass re-keying.
In v2, this concern doesn't exist:
• There are zero existing notification policies (new system)
• Keys are already rotated on every update
• The dispatcher is a single system-level process, not per-rule — it doesn't need the same flexibility to switch key types without re-granting

So the "store both to allow config-driven switching" rationale from v1 doesn't carry over to v2. The v2 dispatcher will know at startup whether
it's running in serverless or not, and can just use the right key type. There's no need to hedge by storing both.
This further supports the discriminated union approach — v2 can just store whichever key type is appropriate for the environment and be explicit
about what it stored.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is UIAM enabled currently on serverless?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed with Mike Cote it's being rolled out this week or so.

Copy link
Copy Markdown
Member

@jasonrhodes jasonrhodes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK mostly LGTM, I just want to confirm on the multi-key situation before approving. Thanks!

}

return [{ id: doc.id, version: doc.version, ...doc.attributes }];
return [{ id: doc.id, version: doc.version, ...omit(doc.attributes, API_KEY_FIELDS) }];
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: does it make sense to use a static method on the class, or just a function outside the class, to handle the omit logic so if we need to extend it or change it, it just happens in one place? Tests will catch it if we miss it so not a big deal, reject this as over-optimization if you like :D

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure thing

expect(result.apiKeyCreatedByUser).toBe(false);
});

it('grants both ES and UIAM API keys when UIAM is available', async () => {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah ok, this behavior also seems to be borrowed from v1 alerting ... if it's necessary then I guess you can ignore my schema / discriminated union idea, but I wonder if we really need this (storing both) if we don't need to migrate or worry about existing objects?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't need both if uiam is already enabled on serverless.

Copy link
Copy Markdown
Member

@jasonrhodes jasonrhodes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kdelemme
Copy link
Copy Markdown
Contributor Author

kdelemme commented Mar 4, 2026

/ci

@elasticmachine
Copy link
Copy Markdown
Contributor

elasticmachine commented Mar 4, 2026

💔 Build Failed

Failed CI Steps

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/alerting-v2-schemas 44 45 +1
Unknown metric groups

API count

id before after diff
@kbn/alerting-v2-schemas 52 53 +1

History

cc @kdelemme

@kdelemme kdelemme merged commit f652a0c into elastic:alerting_v2 Mar 4, 2026
12 of 13 checks passed
@kdelemme kdelemme deleted the alertingv2/handle-api-key-notification-policy branch March 4, 2026 17:45
darnautov added a commit that referenced this pull request Mar 27, 2026
## 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><strong>Core Engine & Plugin Init</strong> (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><strong>Rule Execution Pipeline</strong> (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&#124;QL views (@adcoelho)
- #256697 — Create episodes ES&#124;QL view (@adcoelho)

</details>

<details>
<summary><strong>Alert Suppression & Episodes</strong> (3 PRs)</summary>

- #252174 — Alert suppression (@kdelemme)
- #256486 — Fix suppression query (@kdelemme)
- #256527 — Store 'unmatched' action for unmatched alert episodes
(@kdelemme)

</details>

<details>
<summary><strong>Dispatcher & Notification Engine</strong> (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><strong>Notification Policies (Server)</strong> (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><strong>Notification Policies UI</strong> (1 PR)</summary>

- #255599 — Add notification policies UI and Storybook form story
(@adcoelho)

</details>

<details>
<summary><strong>Rule Authoring UI</strong> (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><strong>API Documentation & Schema</strong> (2 PRs)</summary>

- #254901 — Rename indexes for alert events and actions (@adcoelho)
- #255810 — OAS for alert action routes (@adcoelho)

</details>

<details>
<summary><strong>Observability & Monitoring</strong> (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><strong>CI & Maintenance</strong> (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>
SoniaSanzV pushed a commit to SoniaSanzV/kibana that referenced this pull request Mar 30, 2026
## 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><strong>Core Engine & Plugin Init</strong> (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><strong>Rule Execution Pipeline</strong> (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><strong>Alert Suppression & Episodes</strong> (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><strong>Dispatcher & Notification Engine</strong> (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><strong>Notification Policies (Server)</strong> (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><strong>Notification Policies UI</strong> (1 PR)</summary>

- elastic#255599 — Add notification policies UI and Storybook form story
(@adcoelho)

</details>

<details>
<summary><strong>Rule Authoring UI</strong> (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><strong>API Documentation & Schema</strong> (2 PRs)</summary>

- elastic#254901 — Rename indexes for alert events and actions (@adcoelho)
- elastic#255810 — OAS for alert action routes (@adcoelho)

</details>

<details>
<summary><strong>Observability & Monitoring</strong> (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><strong>CI & Maintenance</strong> (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>
jeramysoucy pushed a commit to jeramysoucy/kibana that referenced this pull request Apr 1, 2026
- **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><strong>Core Engine & Plugin Init</strong> (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><strong>Rule Execution Pipeline</strong> (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><strong>Alert Suppression & Episodes</strong> (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><strong>Dispatcher & Notification Engine</strong> (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><strong>Notification Policies (Server)</strong> (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><strong>Notification Policies UI</strong> (1 PR)</summary>

- elastic#255599 — Add notification policies UI and Storybook form story
(@adcoelho)

</details>

<details>
<summary><strong>Rule Authoring UI</strong> (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><strong>API Documentation & Schema</strong> (2 PRs)</summary>

- elastic#254901 — Rename indexes for alert events and actions (@adcoelho)
- elastic#255810 — OAS for alert action routes (@adcoelho)

</details>

<details>
<summary><strong>Observability & Monitoring</strong> (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><strong>CI & Maintenance</strong> (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>
jeramysoucy pushed a commit to jeramysoucy/kibana that referenced this pull request Apr 1, 2026
- **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><strong>Core Engine & Plugin Init</strong> (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><strong>Rule Execution Pipeline</strong> (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><strong>Alert Suppression & Episodes</strong> (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><strong>Dispatcher & Notification Engine</strong> (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><strong>Notification Policies (Server)</strong> (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><strong>Notification Policies UI</strong> (1 PR)</summary>

- elastic#255599 — Add notification policies UI and Storybook form story
(@adcoelho)

</details>

<details>
<summary><strong>Rule Authoring UI</strong> (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><strong>API Documentation & Schema</strong> (2 PRs)</summary>

- elastic#254901 — Rename indexes for alert events and actions (@adcoelho)
- elastic#255810 — OAS for alert action routes (@adcoelho)

</details>

<details>
<summary><strong>Observability & Monitoring</strong> (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><strong>CI & Maintenance</strong> (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>
paulinashakirova pushed a commit to paulinashakirova/kibana that referenced this pull request Apr 2, 2026
## 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><strong>Core Engine & Plugin Init</strong> (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><strong>Rule Execution Pipeline</strong> (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><strong>Alert Suppression & Episodes</strong> (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><strong>Dispatcher & Notification Engine</strong> (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><strong>Notification Policies (Server)</strong> (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><strong>Notification Policies UI</strong> (1 PR)</summary>

- elastic#255599 — Add notification policies UI and Storybook form story
(@adcoelho)

</details>

<details>
<summary><strong>Rule Authoring UI</strong> (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><strong>API Documentation & Schema</strong> (2 PRs)</summary>

- elastic#254901 — Rename indexes for alert events and actions (@adcoelho)
- elastic#255810 — OAS for alert action routes (@adcoelho)

</details>

<details>
<summary><strong>Observability & Monitoring</strong> (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><strong>CI & Maintenance</strong> (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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author:actionable-obs PRs authored by the actionable obs team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants