Skip to content

Alerting Flows

Evaluation flow

sequenceDiagram
    participant Worker as Alert task
    participant CFG as cConfigExt jobs.alerts
    participant DATA as Message, flow, keystore tables
    participant TYPE as Type-specific evaluators
    participant ALERT as cpiAlert
    Worker->>CFG: Read enabled alert definitions
    Worker->>TYPE: Dispatch by alert type
    TYPE->>DATA: Evaluate current tenant state
    TYPE->>ALERT: Create, continue, suppress, or close alert records
    ALERT-->>Worker: Persisted alert state available for UI

Message, iFlow, keystore, and no-message checks share orchestration but not identical evaluators. That split is important when tracing unexpected alert behavior.

Review flow

sequenceDiagram
    participant UI as AlertPopup
    participant API as CPI alert APIs
    participant ALERT as cpiAlert data
    UI->>API: Load overview, list, statistics, detail
    API->>ALERT: Query persisted alert state
    API-->>UI: Return rows and details

Operational alert review often starts in tenant overview cards and then fans out into message, artifact, or keystore inspection depending on alert type.

Acknowledge flow

sequenceDiagram
    participant U as User
    participant UI as AlertAcknowledgeModal
    participant API as acknowledge endpoint
    participant ALERT as cpiAlert
    U->>UI: Acknowledge alert
    UI->>API: POST acknowledge
    API->>ALERT: Update status
    API-->>UI: Return updated alert state

Acknowledgement changes alert state, but it does not remove the underlying runtime condition. If the triggering condition persists, later evaluation cycles may keep the alert open or create follow-up states depending on the evaluator logic.