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).

Target-Specific Content formats

​

The Content field is evaluated as a Handlebars template and then interpreted according to the Target type you selected for the template.

SMTP (Email) Templates

​

For SMTP templates, the Content field needs to describe a complete email: who receives it, what the subject line is, and what appears in the body.

Normally, SMTP templates include these fields:

• To: Required. One or more recipient email addresses.
• Cc: Optional. Additional visible recipients.
• Bcc: Optional. Additional hidden recipients.
• Subject: Required. Subject line for the Notification.
• Body: Required. The message body, typically HTML, but plain text is also supported.

Use variables like {{monitor_name}}, {{status}}, {{labels.env}}, and {{workspace_name}} to inject context into the subject and body.

Example SMTP template content:

{
  "to": "{{metadata.to}}",
  "cc": "{{metadata.cc}}",
  "bcc": "{{metadata.bcc}}",
  "subject": "[{{status}}] {{monitor_name}}",
  "body": "Severity: {{labels.severity}}\n\nMonitor: {{monitor_name}}\n\nDescription: {{#if description}}{{description}}{{else}}No description{{/if}}\n\nValue: {{value}}\n\nLabels:\n{{#each labels}}  • {{@key}}={{this}}\n{{/each}}{{#if __policyId}}\n\nNotification Policy: {{__policyId}}{{/if}}"
}

Webhook Templates

​

For Webhook targets, the Content field renders to the payload your HTTP endpoint expects.

• Common patterns:

  • NDJSON: One JSON document per line.
  • JSON array: A top-level array of JSON objects.

• Custom JSON object: For APIs that expect a specific wrapper structure, use Handlebars to build it from the alert context, for example:

{
   "monitor":"{{monitor_name}}",
   "status":"{{status}}",
   "fired_at":"{{fired_at}}",
   "workspace":"{{workspace_name}}",
   "labels":{
      "env":"{{labels.env}}",
      "product":"{{labels.product}}"
   },
   "value":"{{value}}",
   "policy_id":"{{__policyId}}"
}

Service-Specific Templates (Slack, PagerDuty, SNS)

​

For Slack, PagerDuty, and AWS SNS targets, treat the Content field as the integration-specific payload required by that service.

Slack

​

Slack content can be simple text or use Slack’s Block Kit for rich formatting.

• Static Structure: If sending as a simple string, use the "text" key within a JSON payload.
• Documentation Link: For advanced layouts and interactive elements, refer to the Slack Block Kit Builder.

PagerDuty

​

PagerDuty typically expects specific fields like summary, source, and severity to correctly categorize incoming incidents.

• Static Structure: Payloads are usually mapped to the PagerDuty Events API v2 schema.
• Documentation Link: See Send an Alert Event in the PagerDuty API Documentation for required field structures and event types.

SNS (Amazon Simple Notification Service)

​

SNS content is usually passed as a plain string or a JSON-serialized string to the configured SNS Topic.

• Best Practice: Ensure the total payload remains under 256KB to stay within AWS published message limits.
• Documentation Link: See Amazon SNS Published Message Fanout for details on message attributes and formatting.

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.