Case title and description templates
A Case title used to be a single fixed string, so ten Cases opened by the same alert definition all read the same and telling them apart meant opening each one. Template the title and description instead and every Case is named for the signal that triggered it, so a responder scanning the list sees the priority, the service, and what fired without opening anything.
Templates use the same engine and the same variables as Notification Center, so any expression that works in your notifications works here. There is no second syntax to learn.
What you need
- The update permission for the alert type you are editing — for example
ALERTS:METRICSUPDATECONFIGfor a metric alert, orALERTS:LOGSUPDATECONFIGfor a log alert. See Alerting permissions. - An alert definition that opens Cases. See Case sources.
Where the templates live
A Case title and description are message fields on the Cases preset, the same way a Slack message or a PagerDuty payload is built from fields on its own preset. That gives you two levels of control:
| Level | What it sets | When to use it |
|---|---|---|
| The Cases preset | The default title and description templates for every Case the preset opens | You want one naming convention across the estate |
| An alert definition | An override of those same fields, for the Cases that alert opens | One alert needs a name the default template cannot express |
To override on a single alert, open the alert definition's notification settings, set what to notify on to Cases, and supply a template for the title or description field on that destination. Over the API or Terraform, the same override is a messageConfigFields entry — a fieldName of title or description plus the template — on the alert's notification destination.
Templates render when the Case opens, once per triggering signal, so each Case carries the values behind its own signal rather than a shared label.
Template a title
This title template:
[{{ alertDef.priority }}] {{ alertDef.name }} on {{ alert.groups["service"] }}
renders as:
[P1] Checkout 5xx spike on checkout-api
The description takes the same templates, so the body can carry signal-specific context too — the metric that broke, the group that triggered, or the alert ID a responder needs to correlate.
What you can reference
Templates read from the triggering signal, so the useful variables are the alert definition and the group values that opened the Case:
| Variable | What it holds | Example |
|---|---|---|
alertDef.name | The name of the alert definition | Checkout 5xx spike |
alertDef.priority | The priority set on the alert definition | P1 |
alertDef.entityLabels["<key>"] | An entity label on the alert definition | payments |
alert.groups["<key>"] | The value of a group-by key for this signal | checkout-api |
alert.highestPriority | The highest priority among the triggering signals | P1 |
For the full schema, including conditionals, filters, and loops, see Dynamic templating. The Case-side variables that notifications read once a Case exists are listed in Cases in Notification Center.
Handle a missing value
A group-by key that does not apply to a given signal renders empty, which leaves a gap in the title. Give the expression a default so the Case still reads cleanly:
[{{ alertDef.priority }}] {{ alertDef.name }} on {{ alert.groups["service"] | default(value="unknown service") }}
To set one fallback for every undefined variable in a template rather than per expression, see Tera syntax.
Rename a single Case
A template decides the name a Case opens with, not the name it keeps. You can still rename an individual Case from its header, and the new name follows it across the Case list, the drill down, and anything referencing it. See Working with Cases.