CT-OpsCT-Ops
Home
Getting Started
Architecture
Features
Deployment
GitHub
GitHub
Home
Getting Started
Architecture
Features
Deployment
GitHub
GitHub
  • Introduction
  • Getting Started

    • Installation
    • Configuration
    • Offline Agent Install Bundle
  • Architecture

    • Architecture Overview
    • Agent Architecture
    • Ingest Service
    • Deployment Profiles
  • Features

    • Hosts & Inventory
    • Host Groups
    • Networks
    • Monitoring
    • Certificate Management
    • SSL Certificate Checker
    • Alerts
    • Notifications
    • Reports
    • Operations Calendar
    • Terminal
    • Service Accounts & Identity
    • Directory User Lookup
    • Tasks & Runbooks
    • Scheduled Tasks
    • Tags
    • Notes
    • Feature Flags
  • Deployment

    • Docker Compose Deployment
    • Air-Gap Deployment
    • Load Testing
  • Development

    • Local Dev Stack
    • End-to-end testing
  • Licensing
  • Security

    • Security & Vulnerability Disclosure
    • mTLS: agent ↔ server authentication

Alerts

Alert rules define the conditions under which CT-Ops generates a notification. Rules are evaluated by the alerts consumer as metrics and check results arrive from the queue.


Alert Rule Concepts

Rule

A condition evaluated against metrics or check results. Examples:

  • CPU > 90% sustained for 5 minutes
  • nginx process not running
  • Port 443 unreachable
  • Certificate expiry < 14 days

Alert instance

When a rule fires, an alert instance is created. The instance tracks the current state of that specific rule/host combination:

  • firing — condition is active
  • resolved — condition is no longer active

Alert instances are never overwritten — each transition (firing → resolved → firing) creates a new record.

Notification

When an alert instance is created or transitions state, a notification is generated and routed to the configured notification channels.


Creating Alert Rules

  1. Open a host and select Monitoring → Alerts
  2. Click Add Rule
  3. Configure:
FieldDescription
NameHuman-readable name for the rule
ConditionMetric or check to evaluate (cpu_percent, memory_percent, disk_percent, check result)
Operator>, <, >=, <=, ==, !=
ThresholdValue to compare against
DurationHow long the condition must be true before firing (e.g. 5 minutes)
Severityinfo, warning, critical
ScopeAll hosts, a specific host, or a host group
ChannelsWhich notification channels to route to
  1. Click Save

Global Metric Defaults

Global alert defaults are metric threshold templates. They are not evaluated for any host until an administrator applies them to that host.

Administrators can apply those defaults when needed:

  • On a host's Alerts tab, Use Metric Defaults replaces that host's host-level metric threshold rules with the current global defaults.
  • On Administration → Monitoring, Apply to Hosts replaces host-level metric threshold rules across all hosts with the current global defaults.

These actions only replace metric threshold rules. Check, certificate, Docker, silence, and notification settings are left unchanged.


Silencing

Alert rules can be silenced for a specified period. Silencing suppresses notifications without deleting the rule. Useful for planned maintenance windows.

  1. Open the rule detail page
  2. Click Silence
  3. Set the duration
  4. Click Confirm

Silences expire automatically. Active silences are shown on the rule detail page with a countdown.


Alert History

The Alerts page shows:

  • All currently firing alerts (top panel)
  • Alert history — all past instances with timestamps, severity, and resolution status

Each alert instance links to the affected host and the rule that triggered it.


Notification Routing

When an alert fires, notifications are routed to the channels configured on the rule. See Notifications for the available channel types and how to configure them.

Edit this page on GitHub
Last Updated: 5/16/26, 8:20 PM
Contributors: Simon Carr, Claude Sonnet 4.6, Claude Opus 4.7
Prev
SSL Certificate Checker
Next
Notifications