Skip to content

Alerts

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 ‣ Alerts

Classification. Why is only the Graph widget alert-capable?

In the Time Series Data Service, alerting is based on the classic panel-bound model. Alerts can only be defined on widgets, and in practice only the Graph widget is relevant for this.

Other widgets such as:

  • Time series
  • Stat
  • Gauge
  • Bar Gauge

do not support alerting in this version.

The Graph widget is therefore:

the central technical carrier for alerting in the Time Series Data Service.

Basic principle of alerting in the Graph widget

An alert in the Graph widget consists of four clearly separated building blocks:

  • Query
    Provides the measurement values from the Time Series Data Service.
  • Conditions
    Check whether defined thresholds or states are reached.
  • Evaluation
    Defines how often and for how long the condition is evaluated.
  • Notification
    Determines who is informed when the alert state changes.

The alert is tightly bound to the Graph widget. If the widget is deleted, the alert is deleted as well.

Which data is used for alerts?

Alerts do not operate on the visualized curve itself, but on reduced time series values.

Typical aggregations are:

  • avg()
  • min()
  • max()
  • last()
  • sum()
  • count()

Example:

  • The Graph widget displays a time series with many data points.
  • The alert checks:
    avg() over the last 5 minutes > 80 percent.

The visualization serves for inspection. The calculation is performed exclusively via aggregation.

Alert conditions in detail

A condition in the Graph widget consists of three parts:

  • WHEN
    Which aggregation is used.
  • OF
    Over which time range the aggregation is calculated.
  • IS ABOVE / BELOW / OUTSIDE RANGE
    Which condition applies.

Example:

WHEN avg() OF query(A, 5m) IS ABOVE 90

Multiple conditions can be combined with AND or OR, but only to a limited extent.

Evaluation intervals and stability

A critical aspect for productive use.

Important parameters are:

  • Evaluate every
    How often the condition is evaluated, for example every 1 minute.
  • For
    How long the condition must be fulfilled before the alert is triggered.

Example:

  • Evaluate every: 1m
  • For: 5m

Result:

Short-term peaks do not trigger an alert immediately. Without a For duration, false positives occur frequently.

Alert states in the Graph widget

An alert in the Graph widget can have the following states:

  • OK
  • Pending
  • Alerting
  • No data
  • Error
  • Paused

All states are first-class and can trigger notifications. Especially the No data state is often more critical in industrial environments than pure threshold violations.

Handling “No data” and “Error”

The Time Series Data Service requires a deliberate decision.

Possible options are:

  • No data = OK
  • No data = Alerting
  • No data = Keep last state

This decision is driven by domain context.

Examples:

  • An energy meter delivers no data. This is critical.
  • Weather data is temporarily missing. This may be non-critical.

Technical limitations of Graph widget alerts

Very important for realistic expectations.

Graph widget alerts cannot:

  • dynamically alert multiple assets,
  • use label-based rules,
  • persist alert states historically,
  • aggregate alerts,
  • control escalations,
  • be acknowledged.

Each alert is:

a single, static threshold on a defined query.

Typical best-practice use cases

Well suited for:

  • Threshold monitoring
  • Availability checks
  • State violations
  • Safety and operational limits

Less suited for:

  • Complex logic
  • Fleet or multi-asset monitoring
  • Adaptive thresholds
  • Data-driven or ML-based anomaly detection

Typical mistakes in practice

Common problems include:

  • Alerts on purely visually optimized graphs
  • Missing For durations
  • Alerts on highly noisy raw data
  • Ignoring the No data state
  • Too many alerts without prioritization

In the Time Series Data Service, alert discipline is more important than the number of alerts.

Short summary

In the Time Series Data Service, the rule is:

Graph widget equals alert engine.

Alerts are:

  • widget-bound,
  • simple,
  • stable,
  • clearly limited in functionality.

They are excellent for clear technical threshold cases, but not suitable for complex operational or escalation logic.