Alerts & Webhooks

Control Tower 5.1.0 introduces user-configurable alert rules and webhook notifications. Rules live in the database, are edited from the control panel, and dispatch notifications to email, Slack, Microsoft Teams, or any HTTPS endpoint via a queued background job.

How alerts work

Each time the alert check runs, Control Tower evaluates every enabled rule against the current value of its metric. If the operator/threshold comparison is true, an alert is created and recorded against the rule. The plugin then queues a SendAlertNotificationJob that delivers the alert to each destination configured on the rule.

• Notification dispatch is asynchronous, so SMTP and webhook latency never block the request that raised the alert.
• An alert is linked to the rule that fired it via the alertRuleId column on controltower_alerts. The Alerts UI shows the rule name in place of the internal type slug.
• If a rule’s condition stops being true and the rule has Notify on resolve enabled, a follow-up “Resolved” notification is sent.

Alert Rules

Manage rules under Control Tower → Alert Rules. Each rule has the following fields:

Metric registry

Rules target one of the metrics exposed by the metric registry. As of 5.1.0:

Default rules

Installs seed five rules so monitoring is useful out of the box:

• Queue has failed jobs — queue_failed ≥ 3, critical
• Multiple editors on same entry — editor_collisions ≥ 1, warning
• CPU usage critical — cpu_percent ≥ 90, critical
• Memory usage critical — memory_percent ≥ 90, critical
• Disk usage critical — disk_percent ≥ 90, critical

Edit, disable, or delete them like any other rule. They’re only seeded when the alert rules table is empty, so they don’t come back after deletion.

Webhooks

Webhook destinations are defined once globally under Control Tower → Webhooks and referenced from any number of rules. Three destination types are supported:

Send test

The webhook edit screen has a Send test button that fires a sample payload at the configured URL and reports the HTTP status inline. Use it to verify connectivity before relying on a destination for real alerts.

Generic JSON payload

The generic formatter emits a flat envelope with the following fields:

{
  "event": "firing" | "resolved",
  "severity": "info" | "warning" | "critical",
  "ruleId": 12,
  "ruleName": "CPU usage critical",
  "metric": "cpu_percent",
  "operator": ">=",
  "threshold": 90,
  "alertId": 4521,
  "alertMessage": "CPU at 94% for 5 minutes.",
  "alertContext": { ... },
  "siteName": "My Craft Site",
  "environment": "production",
  "firedAt": "2026-05-14T14:21:00+00:00",
  "resolvedAt": null,
  "alertUrl": "https://example.com/admin/control-tower/alerts"
}

Email recipients

Each rule can independently notify Craft admins and/or a freeform list of extra addresses. Emails render from templates/_cp/_emails/alert.twig. To customize the look, copy that template into your project’s templates/control-tower/_cp/_emails/alert.twig and edit; Craft’s template overrides apply normally.

Flap throttling

Set Minimum notify interval on a rule (in minutes) to suppress repeat notifications when an alert flaps. The throttle only affects delivery — the alert is still recorded and visible in the Alerts tab on every check.

Permissions

Creating, editing, and deleting alert rules and webhooks requires the Manage alert rules and webhooks permission (controltower:manageAlerts). Viewing the Alerts tab only requires View Control Tower dashboards (controltower:viewDashboard). See Usage → Permissions for the full permission list.