Alerts

Alerts notify your team when DebugBundle detects important events — new incidents, regressions, error spikes, and severity changes. Configure alert rules to route notifications to the right people through the right channels.

How Alerts Work

1. An event triggers in DebugBundle (new incident, regression, spike).
2. The system evaluates all active alert rules for the project.
3. Rules matching the event's conditions and filters fire.
4. Rule-level cooldowns suppress repeated notifications for the same notification key when configured.
5. Notifications are delivered to the configured channel.

Channels

Email

{
  "channel": "email",
  "config": {
    "to": "oncall@mycompany.com"
  }
}

Email alerts send to one recipient per rule. If multiple people should receive email notifications, create multiple alert rules.

Slack

Team workspaces can connect Slack from the project alerts modal. DebugBundle opens Slack OAuth, Slack shows a channel picker, and alert rules store the returned destination ID instead of exposing the webhook URL.

{
  "channel": "slack",
  "config": {
    "slack_destination_id": "11111111-1111-4111-8111-111111111111"
  }
}

Direct webhook_url configuration is still accepted through API, CLI, and MCP for automation that intentionally manages its own Slack webhooks.

Discord

{
  "channel": "discord",
  "config": {
    "webhook_url": "https://discord.com/api/webhooks/..."
  }
}

Webhook

{
  "channel": "webhook",
  "config": {
    "target_url": "https://myapp.com/alerts"
  }
}

Condition Types

Each alert rule has a condition that determines when it fires.

Severity Filter

Alert rules can include a severity_min threshold. When set, the alert only fires for incidents at or above the specified severity:

low < medium < high < critical

For example, severity_min: "high" fires for high and critical incidents only.

Severity is inferred from signal confidence. Backend exceptions, non-opaque frontend exceptions, and immediate request-failure incident signals default to high. Opaque browser-native window_error captures default to low, and opaque resource_error captures default to medium, so a severity_min: "high" rule will not fire from those opaque browser signals alone.

Service Scope

Optionally scope an alert to a specific service using service_id. When set, the alert rule only evaluates events from that service.

Notification Cooldowns

Alert rules can include cooldown_seconds to reduce repeated notifications for the same alert signal. The default is 0, which preserves immediate delivery behavior. A positive value up to 604800 seconds (7 days) suppresses repeated notifications for the same computed notification key while leaving incident grouping unchanged.

For low-information browser-native window_error signals, DebugBundle may use a broader notification key than the incident fingerprint so repeated opaque browser noise can be quieted without merging separate incidents.

The web app shows this setting in whole days for human input. API, CLI, and MCP use seconds (cooldown_seconds, --cooldown, and cooldownSeconds respectively).

Alert Lifecycle

Disable alerts temporarily during maintenance windows or known-issue periods without deleting the rule configuration.

Example: Production Alert Stack

A typical production setup combines multiple alert rules:

Channel: Slack (#incidents)
  Condition: new_incident
  Severity: >= medium

Channel: Slack (#incidents-critical)
  Condition: severity_threshold
  Severity: >= critical

Channel: Email (oncall@company.com)
  Condition: incident_regressed

Channel: Webhook (PagerDuty)
  Condition: error_spike
  Severity: >= high

Managing Alerts

Alerts can be managed through all three interfaces:

Next Steps

• Alerts API — CRUD endpoints for alert rules
• CLI Alert Management — Manage alerts from the command line
• Webhook Events — Events that can trigger alerts