Description
What: We introduced a new error gap fill status for detection rules. When a gap remains unfilled after exhausting all auto-fill retry attempts, it is now classified as error instead of unfilled.
Why: Previously, gaps that could not be auto-filled after multiple retries were still shown as unfilled, making them indistinguishable from gaps that haven't been attempted yet. The new error status improves visibility into rules that are not recoverable by auto-fill, allowing users to identify and act on them separately.
How:
- Enable the auto gap fill scheduler in Rule Settings
- When a gap exhausts all retry attempts, its status changes from
unfilled to error
- In the Rules table, use the gap fill status filter to filter by
Error
- In the Rules with Gaps overview, the summary chart and table show
Error as a separate bucket with its own count and duration
- The
error status is only computed when the gap auto-fill scheduler is enabled. If the scheduler is disabled or unavailable, gaps remain classified as unfilled
Background & resources
Which documentation set does this change impact?
ESS and serverless
ESS release
9.4
Serverless release
After merge to main
Feature differences
API docs impact
API docs impact
Get rules with gaps
POST /internal/alerting/rules/gaps/_get_rules
New optional body parameter:
| Parameter |
Type |
Required |
Description |
gap_auto_fill_scheduler_id |
string |
No |
Scheduler ID used to determine error status. When provided and the scheduler is enabled, gaps that exceeded retry attempts are classified as error. |
Get gaps summary by rule IDs
POST /internal/alerting/rules/gaps/_get_gaps_summary_by_rule_ids
New optional body parameter:
| Parameter |
Type |
Required |
Description |
gap_auto_fill_scheduler_id |
string |
No |
Scheduler ID used to compute error classification in the summary. |
Gap fill status enum
The gap_fill_status enum now includes error across all relevant endpoints:
| Value |
Description |
unfilled |
Gap has not been filled yet |
filled |
Gap has been fully filled |
partially_filled |
Gap has been partially filled |
error |
Gap could not be filled after exhausting all auto-fill retry attempts |
Security Solution Detection Rules APIs
Find rules (GET /api/detection_engine/rules/_find) and Bulk actions (POST /api/detection_engine/rules/_bulk_action) now accept an optional gap_auto_fill_scheduler_id query/body parameter to enable error status classification when filtering or sorting by gap fill status.
Prerequisites, privileges, feature flags
no
Description
What: We introduced a new
errorgap fill status for detection rules. When a gap remains unfilled after exhausting all auto-fill retry attempts, it is now classified aserrorinstead ofunfilled.Why: Previously, gaps that could not be auto-filled after multiple retries were still shown as
unfilled, making them indistinguishable from gaps that haven't been attempted yet. The newerrorstatus improves visibility into rules that are not recoverable by auto-fill, allowing users to identify and act on them separately.How:
unfilledtoerrorErrorErroras a separate bucket with its own count and durationerrorstatus is only computed when the gap auto-fill scheduler is enabled. If the scheduler is disabled or unavailable, gaps remain classified asunfilledBackground & resources
errorgap fill status (scheduler-aware) kibana#259130Which documentation set does this change impact?
ESS and serverless
ESS release
9.4
Serverless release
After merge to main
Feature differences
API docs impact
API docs impact
Get rules with gaps
POST
/internal/alerting/rules/gaps/_get_rulesNew optional body parameter:
gap_auto_fill_scheduler_idstringerrorstatus. When provided and the scheduler is enabled, gaps that exceeded retry attempts are classified aserror.Get gaps summary by rule IDs
POST
/internal/alerting/rules/gaps/_get_gaps_summary_by_rule_idsNew optional body parameter:
gap_auto_fill_scheduler_idstringerrorclassification in the summary.Gap fill status enum
The
gap_fill_statusenum now includeserroracross all relevant endpoints:unfilledfilledpartially_fillederrorSecurity Solution Detection Rules APIs
Find rules (
GET /api/detection_engine/rules/_find) and Bulk actions (POST /api/detection_engine/rules/_bulk_action) now accept an optionalgap_auto_fill_scheduler_idquery/body parameter to enableerrorstatus classification when filtering or sorting by gap fill status.Prerequisites, privileges, feature flags
no