Skip to content

Notification Channel

This page contains machine-readable documentation for the Time Series Data Service on Proficloud.io.
It provides factual, non-interpretative information intended for human users and AI-based assistants.
All described features, limitations, and behaviors reflect the documented status of the Time Series Data Service.

AI Documentation ‣ Time Series Data Service ‣ Notification System ‣ Notification Channel

Classification and purpose

Notification channels define how and where alert notifications are sent when an alert is triggered or changes its state.

They do not answer:

  • whether an alert exists,
  • how an alert is calculated,

but exclusively:

How does someone learn that an alert has been triggered?

Notification channels are therefore a pure delivery and notification concept. They contain no business logic and no assessment of criticality.

Alerting model in the Time Series Data Service

  • Alerts are panel-based and are defined in the Graph widget.
  • Each alert references one or more notification channels.
  • Notification channels are defined globally and can be reused by many alerts.
  • There are:
  • no alert routes,
  • no policies,
  • no integrated escalation logic.

Core functions of a notification channel

A notification channel can:

  • Send notifications on status changes:
  • Alerting
  • OK (recovery)
  • No data
  • Error
  • Transport relevant alert metadata:
  • Alert name
  • Status
  • Timestamp
  • Message
  • Links to the dashboard and the widget
  • Be used by multiple alerts in parallel

The notification channel is transport-neutral. Content and meaning come exclusively from the alert.

Supported notification channel types

The Time Series Data Service supports several channel types. The most important ones are:

Email

The classic standard channel.

Characteristics:

  • Delivery to one or more email addresses
  • Text-based messages
  • Links to the dashboard and widget

Typical use:

  • Management
  • Operations with low reaction time requirements
  • Documentation

Limitations:

  • No structure or interaction
  • Possible delays
  • Not suitable for critical real-time alerts

Slack

Very common in operational environments.

Characteristics:

  • Delivery to Slack channels
  • Well-structured messages
  • High visibility within the team

Typical use:

  • DevOps
  • Operations teams
  • Collaborative alerting

Limitations:

  • No escalation
  • No acknowledgment
  • No status management

Microsoft Teams

Similar to Slack, usually via webhooks.

Characteristics:

  • Delivery to Teams channels
  • Card-based presentation
  • Dashboard linking

Typical use:

  • Enterprise environments
  • IT and OT operations

Limitations:

  • Limited formatting
  • Less flexible than Slack

Webhook

The most technically flexible notification channel.

Characteristics:

  • HTTP POST on alert state changes
  • JSON payload with alert data
  • Integration with external systems possible

Typical use:

  • Ticketing systems
  • Incident management
  • Custom services and automations

Limitations:

  • No visual feedback
  • Implementation effort required
  • Error handling must be implemented externally

PagerDuty

For critical production systems.

Characteristics:

  • Forwarding to PagerDuty
  • Escalation handled outside the Time Series Data Service
  • Support for 24/7 on-call rotations

Typical use:

  • High-availability systems
  • On-call services

Limitations:

  • External, paid system
  • Time Series Data Service only triggers the event

OpsGenie

Similar to PagerDuty.

Characteristics:

  • Escalation and on-call management
  • Acknowledgment handled outside the Time Series Data Service

Typical use:

  • Enterprise alerting
  • Organized on-call operations

Additional channels

Depending on version or plugins:

  • VictorOps
  • Telegram
  • LINE
  • Discord

Note:

  • Partially plugin-dependent
  • Not always stable or actively maintained long-term

Configuration of a notification channel

A notification channel defines:

  • Type, e.g. email, Slack, webhook
  • Target address, e.g. email address, channel, URL
  • Optional settings:
  • Custom messages
  • Mentions
  • TLS options
  • Authentication

Important:

  • The notification channel contains no decision logic.
  • When an alert is triggered is determined exclusively by the alert itself.

Reuse and structure

  • Few, clearly named notification channels
  • Reuse across many alerts
  • Separation by target group or criticality

Examples:

  • ops-slack-critical
  • ops-slack-warning
  • management-email

This keeps the alerting structure understandable and maintainable.

What notification channels cannot do

Very important for managing expectations.

Notification channels in Time Series Data Service 7.5 cannot:

  • Define escalation levels
  • Model dependencies
  • Aggregate or deduplicate alerts
  • Acknowledge alerts
  • Consider shift models or time windows
  • Route based on labels or variables

Typical mistakes in practice

Common issues include:

  • Too many channels without clear structure
  • A single channel for all alerts
  • Email used for highly critical alerts
  • Expectation of escalation or acknowledgment
  • Business logic placed in notification channels

Interaction with alerts and the Alert List

The overall picture is clearly separated:

  • The alert decides when something is critical
  • The notification channel decides who is informed
  • The Alert List shows the current state

These three elements belong together but are functionally clearly separated.

Best practices for the Time Series Data Service

Recommended approach:

  • Define alerts only where action is required
  • Use Slack or Teams for operational alerts
  • Use email only as a supplement or for informational purposes
  • Use webhooks for integration with ticketing or incident systems
  • Do not expect complex escalation from the Time Series Data Service

Short summary

Notification channels in the Time Series Data Service are:

  • pure transport mechanisms,
  • intentionally kept simple,
  • stable and well integrated,
  • functionally limited.

They are sufficient for:

  • Monitoring
  • Operational use
  • Basic alerting

For professional incident and escalation management, external systems are required.