Notification templates control what alert notifications look like. A template defines the structure and content of a message (subject, body, or JSON payload) and can include alert context such as Monitor name, severity, labels, and links. Templates are shared across Monitors and Policies.

Templates are evaluated when an alert is sent to a target:

• Policies or Monitors (using direct targets) decide which targets receive the alert.
• The target and template pairing decides how the message is formatted.

Default Templates

​

Cribl Insights provides out-of-the-box templates for common target types. These default templates are tailored to the channel and include alert context such as the Monitor name, severity, status, timestamps, affected labels, and URLs back to the alert details.

You can clone a default template and adjust it for your needs.

How Templates Fit into Alerting

​

1. A Monitor evaluates its query and rules. When a condition is met, it updates or opens an alert instance.

2. Muting rules and notification policies (or direct targets) decide whether to send notifications and select one or more targets.

3. For each selected target, the template associated (via policy or Monitor) formats the notification payload.

This separation lets you change formatting without touching Monitor thresholds, policies, or targets.

View and Manage Templates

​

1. Go to Insights > Alerts > Notification Settings.
2. Select the Templates tab.

Available actions:

• Create a new template.
• Edit an existing template.
• Clone a template to use as a starting point.
• Delete templates that are no longer needed (after updating any policies or Monitors that reference them.

Create or Edit a Template

​

When you select Add Notification Template or edit an existing one, you configure how notifications for a specific target type should render. Exact fields may vary slightly by target type, but the core structure is similar.

General Settings

​

• Template ID
  A unique, descriptive identifier. This appears in dropdowns when selecting templates from policies or Monitors.
• Description
  A short explanation of when and why to use this template.
• Target type
  The notification target type this template is for. A template is always tied to one target type. Use separate templates if you need different formatting across channels.

Message structure

​

Notification Templates control the payload that Insights sends when an alert fires. Each template is associated with a notification target type, but the configuration always shows a single Content code editor where you define the template body.

Supported target types:

• Webhook
• PagerDuty
• Slack
• SNS
• SMTP

The Content field is interpreted differently depending on the target type (for example, JSON for Webhook/PagerDuty/SNS, Slack Block Kit JSON or text for Slack, HTML/text for SMTP).

Variables and alert context

​

Templates support variables that are populated from the alert and its metadata. Templates use Handlebars-style templates where variables and expressions are written with double curly braces {{ }}, like {{variable_name}}.

The following variables are available in templates:

• {{monitor_id}}: The internal Monitor identifier.

• {{monitor_name}}: The Monitor name.

• {{description}}: Optional Monitor description, if one is configured.

• {{status}}: The current alert status for this alert instance. For example: firing or cleared.

• {{value}}: The metric value that triggered the alert at evaluation time.

• {{labels}}: A map of labels associated with the alert, typically used for routing and matching. You can reference individual labels using dot notation, for example:

  • {{labels.env}}
  • {{labels.product}}

• {{fired_at}}: The Unix timestamp in milliseconds when this alert instance fired.

• {{workspace_name}}: The Workspace name where the alert occurred (useful in multi-Workspace environments).

• {{__policyId}}: The identifier of the notification policy that matched this alert. This variable is evaluated and added only if a notification policy was matched for the alert.

You can use these variables to construct message text, JSON payloads, and deep links. For example, a URL back to the alert details page using {{monitor_id}} and {{workspace_name}}.

Conditionals and Looping

​

Templates can use conditional and looping constructs. For example, to render a list of grouped alerts in a single notification.

if/else conditionals

Use {{#if}}, {{else}}, {{/if}} blocks to include content only when a condition is true.

each loops

Use {{#each}} to list grouped alerts or repeated fields. Inside the block, {{this}} refers to each item.

Use Templates in Policies and Monitors

​

After you define templates, you can attach them in two places:

• Notification Policies
  For each target listed in a policy, you can select which template that target should use. This lets you keep channel-specific formatting in one place while reusing the same policy across many Monitors.

• Monitors (direct targets)
  When a Monitor uses Direct Target Assignment, it can optionally select a template for each target.

Better Practices

​

• Start from defaults
  Clone an included/default template for a given target type and adjust only what you need. This reduces errors and keeps channel conventions consistent.

• Keep it scannable
  Make severity, Monitor name, and key labels (environment, product, component) easy to read in the first line or two. Avoid long, dense payloads unless they are specifically needed.

• Include a link back to context
  Include a link back to the alert details or relevant dashboard/log view so responders can pivot quickly from a notification into investigation.

• Avoid over-embedding data
  For Webhook or SNS targets, be cautious about embedding large or unfiltered data sets. Prefer including identifiers and short summaries, and let downstream systems pull full details.

By using templates consistently, you can standardize how alerts appear across email, chat, incident tools, and automation endpoints while keeping the routing and conditions separate in policies and Monitors.