Skip to main content

Alerts Overview

Alerts are a critical component of the Monad security data pipeline that monitor your pipeline metrics and system health in real-time. They enable proactive monitoring by evaluating conditions against your pipeline's operational metrics and triggering notifications when specific thresholds or patterns are detected.

How Alerts Work​

Alerts operate as monitoring components that continuously evaluate your pipeline metrics and system state. The alert evaluation process follows a consistent pattern:

  1. Metric Collection: Alerts query metrics from your pipelines based on configured time windows
  2. Condition Evaluation: The alert evaluates the current metric values against configured thresholds or conditions
  3. Alert Generation: When conditions are met, alerts are generated with contextual metadata
  4. Notification Delivery: Alerts can be configured as an input to send alerts to any configured output through a pipeline

Common Configuration Patterns​

All alerts share similar configuration concepts:

Alert Rule Configuration​

  • Pipeline IDs: Specifies which pipelines to monitor (empty means all organization pipelines)
  • Severity: Defines the alert severity level (e.g., critical, warning, info)
  • Rule Configuration: Alert-specific settings like thresholds, operators, and time windows

Evaluation Behavior​

  • Continuous Monitoring: Alerts are evaluated at regular intervals
  • Per-Pipeline Alerting: Each pipeline can trigger independent alerts
  • Contextual Metadata: Alerts include relevant context about what triggered them

Alert Structure​

Alert Object Structure​

Alerts generated by the system follow a consistent structure:

{
  "rule_id": "alert_rule_uuid",
  "name": "Alert Rule Name",
  "organization_id": "org_uuid",
  "severity": "critical",
  "description": "Human-readable description of what triggered the alert",
  "metadata": {
    // Alert-specific metadata
  },
  "resource": {
    "resource_type": "pipeline",
    "resource_id": "pipeline_uuid"
  }
}

Severity Levels​

Common severity levels across alerts:

  • "critical": Requires immediate attention
  • "warning": Potential issues that should be investigated
  • "info": Informational alerts for awareness

Best Practices​

Configuration​

  • Set appropriate thresholds based on your pipeline's normal operating ranges
  • Use meaningful alert names that clearly indicate what is being monitored
  • Configure time windows that align with your monitoring needs

Alert Management​

  • Regularly review and tune alert thresholds to reduce noise
  • Use appropriate severity levels to prioritize response
  • Monitor alert frequency to identify systemic issues

Integration with Pipeline Components​

Alerts work seamlessly with other Monad components:

  • Pipelines: Monitor the health and performance of your data pipelines
  • Metrics: Query real-time and historical metrics data
  • Monad Alerts Input: Use the Monad Alerts input to ingest all alert triggers and resolutions into your pipelines, enabling you to route alerts to any destination of your choice through standard pipeline outputs

Managing Alerts in the UI​

The Monad UI provides two main surfaces for working with alert rules: the Alert Rules list where you manage and monitor your rules, and the Alert Rule configuration page where you create and edit individual rules.

Alert Rules List​

The Alert Rules list gives you a central view of every rule configured in your organization. From here you can see each rule's name, type, severity, the pipelines it covers, and whether it is currently active.

Alert Rules list showing rule name, type, severity, monitored pipelines, and active status

Key actions available from this page:

  • Create a new rule using the New Alert Rule button in the top-right corner
  • Edit or delete an existing rule from the row's action menu
  • Filter and search rules by name or type to quickly locate a specific rule in large organizations

Alert Rule Configuration​

Clicking Create New or selecting Edit on an existing rule opens the configuration page. This is where you define the alert type, the conditions that trigger it, and the pipelines it monitors.

Alert rule configuration page showing rule type selection, condition settings, and pipeline scope

The configuration page is organized into three areas:

  1. Rule Details — Set a descriptive name and choose a severity level (critical, warning, or info) that reflects how urgently the alert should be acted on.
  2. Pipeline Scope — Choose which pipelines this rule monitors. Leaving the selection empty applies the rule to all pipelines in your organization. Selecting specific pipelines limits the scope to only those pipelines.
  3. Rule Type & Conditions — Select the alert type (e.g., Threshold, Error Rate, Volume Anomaly, Pipeline Status) and fill in the type-specific settings such as metric name, threshold value, operator, and time window. Each field is described in detail on the individual alert type pages.

After saving, the rule becomes active immediately and begins evaluating your pipelines on the next evaluation cycle.

Live Alert Event Stream​

The alert event stream shows alerts firing in real time across all active rules. Each event displays the rule name, affected pipeline, severity, a human-readable description of what triggered the alert, and the timestamp.

Live alert event stream showing recent alert firings with pipeline name, severity, and description

Use the event stream to:

  • Confirm a new rule is working — after creating a rule, watch the stream to see whether expected alerts appear
  • Triage active incidents — filter by severity or pipeline to focus on the most urgent events
  • Spot patterns — repeated alerts from the same pipeline can indicate a systemic issue worth investigating in the pipeline's metrics view

End-to-End Example: Routing Alerts to Pagerduty​

A common way to derive value from the alert service is to route alert events into a notification channel so your team is notified automatically. The general flow is:

  1. Create an alert rule on the Alert Rules configuration page (e.g., a Pipeline Status Alert watching for sustained Erroring status)
  2. Add a Monad Alerts input to a new or existing pipeline — this input streams every alert event generated by your rules as structured JSON
  3. Connect a Pagerduty (or other) output to the same pipeline and configure the destination channel
  4. Save and activate the pipeline — from this point on, every time the alert rule fires, the event flows through your pipeline and posts to Pagerduty

This pattern works with any Monad output, allowing you to send alerts to ticketing systems, SIEMs, data warehouses, or any other destination your organization already uses.