Skip to content

Alerting Type Matrix

This page maps the concrete alert types, important fields, and typical values currently used in the project defaults and runtime logic.

Shared alert shape

Every alert definition inside jobs.alerts.config.alerts[] follows the same high-level structure:

Field Meaning Example values
id Stable alert definition id stored later as alert_conf_id UUID string
name Human-readable alert label Message Failed, iFlow Error
severity Intended alert level warning, error
type Evaluator family alert_messages, alert_iflows, alert_keystore, alert_iflow_no_messages_daily
enabled Whether this definition is active true, false
tags Optional tag filter layer [], ["sap", "critical"]
packages Optional package scoping [] or selected package names
notifications.email.enabled Email notification toggle true, false
notifications.email.recipients Explicit recipients [], ["ops@example.com"]
notifications.email.template_key Email template lookup key message_failed, iflow_error
suppress_minutes Re-alert suppression window 60, 1440

Type matrix

Type Primary object Key status fields Typical defaults Main evaluator
alert_messages message objects.message.status, customstatus, customheaders, logic status ["failed"], suppress 60 alerts_message.py
alert_iflows iflow objects.iflow.status status ["error"], suppress 60 alerts_iflow.py
alert_keystore keystore objects.keystore.status status ["expiring_28_days"] or ["expired"], suppress 1440 alerts_keystore.py
alert_iflow_no_messages_daily iflow plus daily window daily_check.window_hours, min_messages, weekdays, objects.iflow.ids window_hours=24, min_messages=0, weekdays 1..7, suppress 1440 alerts_iflow_no_messages.py

Message alert example

{
  "name": "Message Failed",
  "severity": "error",
  "type": "alert_messages",
  "enabled": false,
  "objects": {
    "message": {
      "logic": "AND",
      "status": ["failed"],
      "enabled": true,
      "customstatus": [],
      "customheaders": [],
      "customheaders_logic": "OR"
    }
  },
  "suppress_minutes": 60
}

Important evaluator ideas:

  • status narrows the CPI message state
  • customstatus can add a second domain-specific filter layer
  • customheaders can act as technical routing or business-context filters
  • logic and customheaders_logic influence how the conditions are combined

iFlow alert example

{
  "name": "iFlow Error",
  "severity": "error",
  "type": "alert_iflows",
  "enabled": false,
  "objects": {
    "iflow": {
      "status": ["error"],
      "enabled": true
    }
  },
  "suppress_minutes": 60
}

Typical meaning:

  • monitors persisted artifact or deployment state, not raw live CPI state
  • often leads operationally into Artifacts

Keystore alert example

{
  "name": "Keystore Entry Expiring Soon",
  "severity": "warning",
  "type": "alert_keystore",
  "enabled": false,
  "objects": {
    "keystore": {
      "status": ["expiring_28_days"],
      "enabled": true
    }
  },
  "suppress_minutes": 1440
}

Observed default statuses in the project:

  • expiring_28_days
  • expired

Operationally, these alerts depend on synchronized keystore inventory from Keystore Entries.

Daily no-message alert example

{
  "name": "iFlow No Message (daily)",
  "severity": "warning",
  "type": "alert_iflow_no_messages_daily",
  "enabled": false,
  "objects": {
    "iflow": {
      "enabled": true,
      "ids": []
    }
  },
  "daily_check": {
    "window_hours": 24,
    "min_messages": 0,
    "weekdays": [1, 2, 3, 4, 5, 6, 7]
  },
  "suppress_minutes": 1440
}

Important meaning:

  • ids can narrow the check to selected iFlows
  • window_hours defines the observation horizon
  • weekdays uses numeric weekday values
  • the evaluator also writes runtime state to avoid losing daily cadence information

Runtime and persisted alert rows

The alert definition is not the final alert record. Triggered alert rows are persisted in:

  • cpiAlert
  • cpiMessageAlert
  • cpiFlowAlert
  • cpiKeystoreEntryAlert

Key persisted row fields include:

Field Meaning Example
level persisted alert level error
object primary object family message, iflow, keystoreentry
status runtime alert state alerted, acknowledged, outdated
reason textual reason evaluator-specific text
alert_conf_id link back to definition id definition UUID
time_alerted first or current alert time ISO timestamp
origin_alert earlier alert chain reference UUID or null

What to inspect first

  • use Flows to see how type-specific evaluators are dispatched
  • use Message Popups when a message alert needs deeper runtime inspection
  • use Worker Runtime Overview to understand scheduling cadence and upstream dependencies