Skip to content

Alert Rules, Filters, and Notifications

What this page helps with

This page explains how alerting is configured from a user and operator perspective:

  • which alert types are available
  • how alerts are narrowed to relevant objects
  • how notifications are sent
  • how to keep alerting useful instead of noisy

Core alert decisions

Every alert rule should answer four questions:

  1. what should be monitored
  2. how serious the condition is
  3. who should be notified
  4. how repetition or suppression should behave

If one of these points is unclear, the rule is usually too broad or too hard to operate.

Typical alert types

IntegraMon currently supports alerting around topics such as:

  • message processing problems
  • artifact or iFlow deployment status
  • keystore or certificate conditions
  • daily checks for missing message activity

Choose the alert type that best matches the operational question you want to answer.

Filters and scope

Alerting becomes useful when it focuses on the right scope.

Typical filter dimensions are:

  • tags
  • packages
  • object-specific conditions
  • status-related conditions

Good practice:

  • start with a narrow scope
  • expand only after you are sure the signal is useful
  • avoid mixing too many unrelated conditions into one rule

Severity

Severity should reflect operational urgency, not personal preference.

A helpful pattern is:

  • low severity for informational checks
  • medium severity for issues that need review
  • high severity for conditions that need action quickly

If every alert is critical, teams stop trusting the system.

Notifications

Alert rules can trigger notifications for the people who should react.

Typical notification topics:

  • recipient list
  • template choice
  • enabled or disabled delivery

Use recipient lists that match responsibility. For example:

  • technical support for runtime failures
  • certificate owners for expiration issues
  • tenant operations for daily monitoring gaps

Repetition and suppression

Alerting should stay visible without becoming repetitive noise.

Important settings usually include:

  • repeat interval
  • suppression period
  • temporary ignore behavior

Use longer suppression where repeated notifications add no value, and shorter repetition where ongoing awareness is operationally important.

Practical examples

Message failure alert

Useful when:

  • failed messages need quick attention
  • only certain packages or scopes matter
  • the right support team should receive mail

Certificate expiration alert

Useful when:

  • keystore entries approach their end date
  • certificate owners need early warning
  • the rule should not fire too late

Daily no-message check

Useful when:

  • expected traffic should arrive every day
  • silence itself is a warning sign
  • one missed day should trigger review

Common mistakes

  • defining very broad rules for all objects at once
  • sending every alert to the same mailbox
  • using high severity for everything
  • creating repeated alert noise without suppression logic
  • mixing unrelated operational concerns in a single rule