CT-Ops

Checks & Alerts

Operator guide for the CT-Ops Alerts page, alert history, silences, and notification channels.

The Monitoring -> Checks & Alerts menu item opens /alerts. Use this page as the alert triage and delivery-control centre for the current CT-Ops instance.

The page shows active alert instances, historical alert instances, maintenance silences, and notification channels. It does not create alert rules directly. Create host check alert rules from Host Monitoring or service alerts from Host Infrastructure. Global check templates and default check-alert rules are managed under Global Checks.

Access and refresh behaviour

Users with instance access can view alert instances, silences, and notification channels. Creating notification channels and sending test notifications require administrator access. Acknowledging alerts and creating or deleting silences require write access.

The active alert list refreshes every 30 seconds. Notification channels and silences refresh every 60 seconds. Alert history is collapsed by default, shows the matching history-item count in the header, and loads rows in pages of 25 after an operator opens it.

Alert and silence timestamps are shown with the instance Display Settings.

Active alerts

The page header shows the total number of active firing alerts. The Severity filter narrows the active list to All severities, Critical, Warning, or Info without changing alert history.

The Active Alerts table lists currently firing alert instances.

Use Incident when the alert needs incident tracking. CT-Ops creates an incident from the alert, invalidates the alert data, and redirects to the new incident page.

Use Acknowledge when an operator has accepted ownership or deliberately suppressed continued active-alert triage for that instance. Acknowledgement changes the instance status from firing to acknowledged, records the acknowledgement time and user, and removes the row from the active table. It does not disable the alert rule. If the underlying condition resolves and then fires again later, CT-Ops creates a new alert instance.

Alert history

Alert History is collapsed by default so active triage stays at the top of the page. The header shows the number of matching history items while the table is closed. Use Show history to expand firing, resolved, and acknowledged alert instances, newest first. It is useful for handover, post-incident review, and identifying noisy rules.

The history table columns are:

Use history to confirm whether a condition is still active, how often a rule fires, and whether alert volume lines up with maintenance windows or metric pressure on the host.

Silences

Silences suppress alert evaluation during planned work. CT-Ops checks active silence windows before evaluating host, Docker container, and Docker image alert rules. An instance-wide silence applies to every host; a host-specific silence applies only to the selected host.

Select Add Silence to open the silence form.

The silences table columns are:

Use silences for planned maintenance, controlled restarts, known noisy dependencies, or temporary infrastructure work. Prefer host-specific silences when only one machine is affected; use instance-wide silences only for broad platform events where every alert would be expected noise.

Notification channels

Notification Channels defines where alert fired and resolved events are sent. CT-Ops supports webhook, email, Slack, and Telegram channels. Channel configuration is instance-scoped.

Global in-app notification routing and central SMTP relay settings live in Notification Delivery Settings. Email channels store recipients only; they use the global SMTP relay for delivery.

The notification channels table columns are:

Action controls:

After a test, CT-Ops opens a test-result dialog. Success confirms delivery was accepted by the destination or SMTP relay. Failure shows the returned error, such as an HTTP status, Telegram response body, SMTP relay error, or timeout.

Webhook channels

Select Add Webhook to send alert events to a custom HTTPS endpoint.

Editing a webhook requires Name and URL again. Leave Secret blank to keep an existing secret; enter a new value to replace it.

Use webhooks for incident platforms, custom automation, or ticketing systems that can accept CT-Ops alert events.

Email channels

Select Add Email to route alert events to one or more email recipients.

Editing an email channel lets administrators rename it or replace the recipient list. Email delivery requires the global SMTP relay to be enabled and valid. See Notification Delivery Settings.

Use email channels for shared operations mailboxes, escalation lists, or teams that do not use chat or webhook integrations.

Slack channels

Select Add Slack to send alerts to a Slack incoming webhook.

When editing Slack, the webhook URL field can be left blank to keep the existing stored URL. Enter a new HTTPS webhook URL to rotate the destination.

Use Slack channels for operational rooms where responders already coordinate active incidents.

Telegram channels

Select Add Telegram to send alerts through a Telegram bot.

When editing Telegram, leave Bot Token blank to keep the existing token. The Chat ID field is always editable.

Use Telegram channels when the operations team uses Telegram for out-of-band or mobile alert delivery.

Alert rule sources

Alert instances shown on this page can come from several rule types:

Severity values are Info, Warning, and Critical. Rule forms default severity to Warning unless the creating workflow overrides it.

Use the /alerts page for response and delivery operations. Use the host and settings pages linked above when the rule definition itself needs to change.