Message Summary Templates

Template Entities

Message summary formatting uses three interconnected entities that determine both the summary format and visual presentation. These entities work together in a hierarchical relationship.

• event_type_category: determines which templates to apply

• summary_template: defines the display format

• indicator_template: controls the color coding

When a log message arrives with a gim_event_subcategory field (like service.configuration), Graylog matches it to an event type category entity. That event type category references both a message summary template (which formats the display) and an indicator template (which applies color coding). The templates use field placeholders in curly braces like {field_name} that get replaced with actual values from your log messages.

For example, if you have a template with the summary format [Alert] service_name:{service_name} | user_name:{user_name}, and a log message contains service_name: "Windows Defender" and user_name: "User1234", the displayed summary becomes [Alert] service_name:Windows Defender | user_name:User1234.

Event Type Category

The event type category entity determines which messages receive specific summary and indicator templates based on the gim_event_subcategory field. This field combines the category and subcategory values with a dot separator to match messages to their appropriate templates. When a log message arrives with gim_event_subcategory=service.configuration, the system applies the associated summary template and indicator template defined for that category.

Event type categories reference templates by name using a specific naming convention. The summary_template field uses the format summaryTemplate.template_name to point to a reusable message summary template object, while the indicator_template field uses indicatorTemplate.template_name to point to an indicator template object. This reference structure allows multiple event categories to share the same templates when required for similar display formatting.

{
  "title": "serviceStart",
  "description": "Service Start Summary (schema v3.1)",
  "category": "service",
  "sub_category": "start",
  "summary_template": "summaryTemplate.serviceCategory",
  "indicator_template": "indicatorTemplate.serviceStateIndicator",
  "default_indicator": "default"
}

summary_template: '[{gim_event_type}] {source_ip} - {destination_ip}'

Message Summary Templates

Message summary templates are reusable template objects that control the message format. They must be referenced by the event type category summary_template field using the summaryTemplate.template_name format. These templates define how log messages appear in the collapsed search results view by specifying which fields to display and how to arrange them using field placeholders. They include the following fields:

• template_id: The unique reference ID to be used by other entities.

• summary : The desired message format, with field placeholders denoted with curly braces {<field_name>}.

• title: A plain language title.

• (Optional) description: A plain language description.

Indicator Templates

Indicator templates control the color coding applied to log messages based on field values, providing visual prioritization cues in search results. These templates work by inspecting a specific message field and applying color-based styling according to predefined value arrays, enabling security analysts and operations teams to quickly identify critical events, warnings, and normal operations through visual scanning without reading detailed message content. They include the following fields:

• type: The unique reference ID to be used by other entities.

• title: A plain language title.

• (Optional) description: A plain language description.

• indicator: The field in the message to determine what color key to use.

• default_indicator: The color key to use if no matches are found.

• danger/info/primary/success/warning: (for one or more keys) Array of indicator field values that will trigger the message to be displayed in the <key> color.

Consider the following example:

{
  "type" : "serviceStateIndicator",
  "title" : "Service State Indicator",
  "description" : "Set summary font color for different service state events",
  "success" : [
      "service installed",
      "service enabled"
    ],
  "danger" : [
      "service error",
      "service disabled",
      "service removed"
    ],
  "indicator" : "gim_event_type",
  "default_indicator" : "info"
}

In this example, Graylog checks the value of the gim_event_type field. If the value is service error, service disabled, or service removed, Graylog applies the danger color (red). If the value is service installed or service enabled, Graylog applies the success color (green).

For example, a log message with the fields gim_event_type: "service error", service_name: "Windows Defender", and user_name: "User1234" would appear in the danger color as follows: [service error] service_name:Windows Defender | user_name:User1234.

A log message with the fields gim_event_type: "service enabled", service_name: "Windows Defender", and user_name: "User1234" would appear in the success color as follows: [service enabled] service_name:Windows Defender | user_name:User1234.

Indicator templates support multiple color categories, including danger, info, primary, success, warning, gray, and a default fallback value. These mappings generally follow familiar UI conventions. For example, danger is typically used for errors or harmful changes, success for normal or expected positive states, and warning for conditions that may require attention. The appearance of these colors can be customized globally, and those customizations apply for all users in both light and dark themes.