stack kb security-detections-api set-alerts-status cli command
Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is in technical preview and is ready for evaluation. Use with caution in production; it is not recommended for mission-critical workloads. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. Specific Support terms apply. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability This functionality is in technical preview and is ready for evaluation. Use with caution in production; it is not recommended for mission-critical workloads. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. Specific Support terms apply. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Serverless
Preview
Preview
Stack
Preview
Preview
elastic stack kb security-detections-api set-alerts-status \
--status <status> \
[options]
Set a detection alert status
Behaviour flags:
--dry-run — validate all inputs and exit without performing any action
--statusenumrequired-
Values: open, acknowledged, in-progress
--reasonstring--signal-idsstring[]-
List of alert ids. Use field
_idon alert document orkibana.alert.uuid. Note: signals are a deprecated term for alerts.Repeatable: pass
--signal-idsmultiple times to supply more than one value --conflictsenum-
Values: abort, proceed
--querystring--runtime-fieldsstring- Optional map of field name to runtime field type. For each entry, a runtime field of the specified type is created reading its value from
_source[fieldName]and included in the query asruntime_mappings. Use this to reference fields stored on the alert_sourcethat are not part of the Elastic Common Schema (ECS) of the alerts index mapping, for example, custom fields that the rule's source index defined when the alerts were created. --runtime-mappingsstring- Use this when the query references fields that are not in the alerts index mapping, for example data view runtime fields with a Painless script.
Kibana sends
type,script.source, andformatto Elasticsearch asruntime_mappingson the status-update query. Unlikeruntime_fields, Kibana keeps your script and runs it at query time. It does not replace the script with a_sourcereader. When a script is present, Kibana setson_script_errortocontinue. If the script fails on one alert, that field has no value for the alert and the update continues. Unique field names acrossruntime_fieldsandruntime_mappingscombined cannot exceed 100. Larger maps are rejected. --input-filestring- path to a JSON file to use as command input
--dry-run- validate all inputs and exit without performing any action (preview changes without applying them)
--no-validate- skip input validation and send the request as-is
--output-fieldsstring- comma-separated list of fields to include in output (dot-notation supported)
--output-templatestring- Mustache-like template for custom text output (e.g. "{{id}}: {{name}}")
--json-
output as JSON