Summary
When editing an Alerting v2 rule that was created via the YAML editor with a configuration the form cannot represent, the rule edit flyout now forces YAML-only mode and disables the Form/YAML toggle. Previously, opening such rules in the UI would silently drop the unrepresentable fields on save. The tooltip on the disabled toggle reads: "The current YAML configuration contains features that cannot be represented in the GUI." The sandbox also opens automatically so users can still test queries interactively.
Why this needs docs: Users writing rules in YAML need to know which configurations are non-representable in the form, so they understand why the toggle is disabled when they reopen a rule.
Resources
- PR #274207 — [Alerting v2] Force YAML mode for non-representable rule configurations
Availability
| Channel |
Details |
| Stack |
v9.5.0 |
| Serverless |
~Jun 29–Jul 3 |
| Feature flag |
Alerting v2 preview |
Suggested edits
Wherever the Alerting v2 YAML rule schema is documented (the rule authoring reference or YAML editor how-to), add a section or note covering the non-representable cases:
| YAML configuration |
Why the form can't represent it |
query.format: standalone with alert kind |
Form is built around the composed format (base + segments) |
recovery_strategy: no_breach |
Form only supports query (custom recovery queries) |
recovery_strategy: none |
Form only supports query (custom recovery queries) |
no_data_strategy (any active value) |
Form has no UI for no-data handling |
query.no_data block |
Form has no UI for no-data queries |
When one of these is present, the Form/YAML toggle is disabled. The YAML editor remains fully functional and all fields round-trip without loss. Applies from 9.5.0 and in serverless (Alerting v2 preview).
Summary
When editing an Alerting v2 rule that was created via the YAML editor with a configuration the form cannot represent, the rule edit flyout now forces YAML-only mode and disables the Form/YAML toggle. Previously, opening such rules in the UI would silently drop the unrepresentable fields on save. The tooltip on the disabled toggle reads: "The current YAML configuration contains features that cannot be represented in the GUI." The sandbox also opens automatically so users can still test queries interactively.
Why this needs docs: Users writing rules in YAML need to know which configurations are non-representable in the form, so they understand why the toggle is disabled when they reopen a rule.
Resources
Availability
Suggested edits
Wherever the Alerting v2 YAML rule schema is documented (the rule authoring reference or YAML editor how-to), add a section or note covering the non-representable cases:
query.format: standalonewithalertkindrecovery_strategy: no_breachquery(custom recovery queries)recovery_strategy: nonequery(custom recovery queries)no_data_strategy(any active value)query.no_datablockWhen one of these is present, the Form/YAML toggle is disabled. The YAML editor remains fully functional and all fields round-trip without loss. Applies from 9.5.0 and in serverless (Alerting v2 preview).