PDF

Managing Alerting Message Formats

Message formats define how alert data is rendered and delivered across notifications, integrations, and automated actions. They provide a reusable, consistent, and highly customizable layer between events and alerting mechanisms.

Purpose of Message Formats

SettingsAlerting & NotificationsPoliciesAlerting Message Formats

In NetCrunch, message formats control how event information is transformed into textual output used by alerting actions such as emails, SMS messages, syslog records, scripts, or external integrations.

Instead of embedding message text directly into alert rules or actions, NetCrunch separates:

  • Event detection – what happened
  • Action execution – what should be done
  • Message rendering – how the information is presented

This separation allows message content to evolve independently from monitoring logic and ensures consistency across all alerting channels.

Where Message Formats Are Used

Message formats are consumed by most alerting and automation mechanisms, including:

  • Email notifications
  • SMS and short-message gateways
  • Syslog forwarding
  • Ticketing and integration connectors
  • Script execution (local, remote, SSH)
  • Writing to files or system logs

The same event can therefore produce different representations depending on the delivery channel, without duplicating alert rules or actions.

Message Variants

A single message format can contain multiple variants, each optimized for a specific output channel or purpose.

Each variant is written in one of four formats, and the fields you get depend on which:

Plain Text
A single Message field. This is what SMS gateways, scripts and file output consume.
Syslog Message
A Message plus Facility and Severity, so the record arrives correctly classified at the collector.
Email (Plain Text)
Subject and Body.
Email (HTML)
Subject and a body built from a Header, one or more Sections, and a Footer — see below.

Variants allow you to control verbosity and structure without redefining the core message logic.

On Alert and On Close

Every variant is written twice, on two tabs: On Alert and On Close.

An alert firing and the same alert clearing are different messages with different useful content — the first needs the problem and its context, the second usually needs little more than confirmation and how long it lasted. Writing both is what stops a closing notification reading like a second outage.

Event Scope of Message Formats

Message formats can be defined at different levels of scope:

Global (Default) Formats

Global formats act as system-wide defaults. They are used whenever no more specific format is defined for an event or rule.

This ensures that every alert action always has a valid message representation.

Event Class–Specific Formats

Formats can be assigned to an event class, applying to all rules that belong to that class.

This is useful when a group of related events requires: - A common structure - Shared terminology - Consistent parameter usage

Rule-Specific Formats

For maximum precision, formats can be overridden for individual event rules.

Rule-specific formats are ideal when: - A particular event needs additional context - External integrations require a custom layout - Certain alerts must be more concise or more verbose than others

Parameters and Dynamic Content

Message formats are built using parameters, which are resolved dynamically at runtime.

Parameters may include:

  • Common event metadata (time, severity, state)
  • Source object information (node, device type, address)
  • Event-specific properties
  • Extended data provided by sensors or monitoring logic

This allows a single format definition to adapt automatically to different events and objects.

Inserting a Parameter

A parameter is written as $Group.Name — a dollar sign, the parameter group, a dot, and the parameter.

You do not have to memorise them. Use Insert Parameter… in the editor and pick from the list, which is built from the event class you are writing for: choosing a specific event rule narrows the list to the parameters that event actually carries.

Sections

An HTML email body is assembled from sections, and three of them build themselves from live data rather than from text you write:

Event Parameters
Lists all alert parameters dynamically.
Node Service Status
Lists the state of every network service on the monitored host.
Traceroute Data
Includes the traceroute to the monitored host.

Anything else is a Custom Section you write yourself.

The self-building sections are the ones worth reaching for first. A Node Service Status section answers "what else on this host is broken?" without anyone having to ask, and it costs one click rather than a dozen parameters.

Reuse and Consistency

One of the key advantages of message formats is reuse.

  • The same format can be referenced by multiple actions
  • Updates to a format automatically affect all consumers
  • Teams can standardize alert wording across departments and tools

This is especially valuable in larger environments where alerts are consumed by: - Operations teams - External systems - Automation workflows

Default Message Formats for Actions

NetCrunch allows you to define default message formats per action type.

SettingsAlerting & NotificationsPoliciesDefault Alerting Message Formats

This establishes a clear baseline, for example: - Emails use a detailed format - SMS uses a short format - Syslog uses a structured format - Scripts receive a predictable text payload

Defaults reduce configuration effort while still allowing overrides when needed.

Design Best Practices

When designing message formats, consider the following guidelines:

  • Keep human-facing messages readable
  • Keep machine-facing messages predictable
  • Avoid unnecessary verbosity for high-frequency alerts
  • Use extended parameters only where they add value
  • Prefer reuse over duplication

A well-designed set of message formats significantly improves alert clarity, reduces noise, and simplifies integrations.

Conceptual Summary

Message formats are a core abstraction in NetCrunch alerting:

  • They decouple alert content from alert logic
  • They enable consistent communication across channels
  • They scale from simple notifications to advanced integrations

By treating message rendering as a first-class concept, NetCrunch allows alerting to remain flexible, maintainable, and future-proof.

alertsautomationintegrationsmessage-formatsnotifications