Creating observability rules - cases

Elastic Observability
1

I have created Observability rules in Kibana and integrated the Cases action to enable auto-generated cases. Initially, I faced a limitation where I couldn't customize the case payload to extract critical alert details. This made it difficult to immediately identify what was wrong with a specific host or determine the correct team assignment.

can anyone give me a solution

2

Hi,

Based on the information shared so far, I would separate this into two different things: creating Kibana Cases automatically, and dynamically customizing the full case payload.

The native Cases action is mainly intended to create Kibana Cases when alerts occur. In the documented configuration, the Cases connector exposes options such as Group by alert field, Time window, Template name, Auto-push case to connected external system, maximum number of cases, and whether to reopen a closed case. The same documentation also states that the Cases connector cannot be managed in Stack Management > Connectors or by using APIs, and that you can have only one Cases action in each rule.
Reference: Cases connector and action | Kibana

So, unless there is a version-specific feature or another configuration detail not mentioned here, I would not expect the native Cases action alone to behave like a generic payload editor where you can freely map arbitrary alert fields into the case body.

If you want to stay with the native Cases action, the best approach is usually to make sure the important triage fields are present in the alert itself, for example:

host.name
service.name
kibana.alert.reason
labels.team
labels.owner
environment

Then use Group by alert field in the Cases action. By default, all alerts are attached to the same case, but Elastic documents that you can optionally choose a field to group alerts, and Kibana will create a unique case for each group.
Reference: Cases connector and action | Kibana

You can also look at Case templates and custom fields to standardize the case structure. Elastic documents that templates can pre-fill fields such as severity, tags, title, description, and custom fields, which helps keep cases consistent across the team.
Reference: Configure case settings | Elastic Docs

However, I would treat templates as case standardization, not as full dynamic payload transformation, unless your exact Kibana version documents support for the dynamic mapping you need.

If your requirement is to build a fully customized payload with alert details, host information, routing information, and team assignment, I would use an additional action such as Webhook, Email, or Index connector. Kibana alerting actions support Mustache variables, and Elastic documents that the available variables differ by rule type.
Reference: Rule action variables | Elastic Docs

A useful first step is to use {{.}} in a webhook or email action to inspect the full variable context exposed by your specific Observability rule. Elastic documents this as a way to see all alert-specific variables.
Reference: Rule action variables | Elastic Docs

For example, a webhook payload could start with something like this and then be adjusted after checking the real variables available in your rule:

{
"rule_name": "{{rule.name}}",
"rule_id": "{{rule.id}}",
"rule_url": "{{rule.url}}",
"alert_reason": "{{context.reason}}",
"alert_details_url": "{{context.alertDetailsUrl}}"
}

The exact context.* fields depend on the rule type, so I would first test the available variables and then replace the generic payload with the specific fields you need.

If you need full control over the Kibana Case content itself, the most flexible design would be:

Observability rule
-> Webhook action
-> Middleware/service
-> Kibana Cases API

The middleware can enrich the alert, calculate the right team assignment, format the case description, and then call the Kibana Cases API to create a case or add comments/alerts to an existing case. Elastic documents that Cases can contain assignees, tags, severity, status, alerts, comments, and visualizations.
Reference: Cases | Kibana API documentation

The Kibana Cases API also provides an endpoint to add a comment or alert to an existing case.
Reference: Add a case comment or alert | Kibana API documentation

So the practical answer is:

Simple automatic case creation:
Use the native Cases action + Group by alert field + Case templates.

Dynamic payload or custom routing:
Use Webhook, Email, or Index connector with Mustache variables.

Full control over the Case content:
Use Webhook + middleware + Kibana Cases API.

It would also help to know your exact Kibana version and the Observability rule type you are using, because the available action variables can differ by rule type and version.

3

thank you very much, I will try what you advice me with and update you shortly