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 Threshold Lifecycle

severity_threshold rules can notify on new incidents, incident regressions, or both. The default is both, so a threshold rule with severity_min: "medium" matches medium, high, and critical incidents when they are first opened and when they later regress.

Use severity_lifecycle_scope in the API, --severity-lifecycle-scope in the CLI, severityLifecycleScope in MCP, or the dashboard's "Notify on" field to choose:

Non-threshold alert conditions do not use this field because their condition already defines the lifecycle event.

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. A one-day cooldown is not a daily reminder; it means the same matching notification key can send at most once per day.

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
  Notify on: new incidents and regressions

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

Dashboard rule controls

Create and edit use the same existing form. Cooldowns have explicit seconds, minutes, hours or days units and retain exact whole-second values. Choose Any severity to clear a previous filter, scope a rule to one service or all services, and enable or disable it without deleting it. Email digest windows accept 1–300 seconds; immediate-channel rules can use incident or project cooldown scope.

Custom alert webhooks can reveal their signing secret at creation or rotate it explicitly while editing. Rotation replaces the active key immediately; update the receiver with the new key. Secrets appear once and do not enter the rule list. Grouped deliveries below the rules show direct notifications and email digests; inspect a group to page through its incident members.

Pause notifications or receive a daily email

Open Account Settings → Notifications to set defaults across projects, or Project Settings → Notifications for a project override. Choose My email for your own delivery or Shared destinations to affect the team. Shared changes require the account owner or a project owner/admin.

Pause selected channels for 24 hours, seven days, a custom end time, or until you resume. Account pauses override project settings; resuming a project cannot undo an account pause. Pausing preserves delivery modes and does not stop monitoring. Suppressed alerts are not replayed afterwards. All channels includes future configured destinations in that scope.

Choose Daily digest for email, set a local time and IANA time zone (or use the device time zone), and leave Slack on Immediate. Daily email groups new or reopened incidents still unresolved at send time by project. Empty periods send no email, and unchanged incidents are not repeated. Health-check outages remain immediate in daily mode. Explicit off/pause can silence them; the pause form lets you keep health-check alerts enabled.

Changing the daily time updates pending mail, including when you move it earlier. Switching to Immediate sends eligible queued incidents in a summary, while other projects keep their own schedules. Paused or switched-off history is not replayed.

These settings also apply to optional weekly reports. Sign-in, security, billing, invites and mandatory operational account notices remain enabled. Signed lifecycle webhooks and GitHub automation are separate from alert notifications.

Existing rules still determine which incidents and recipients qualify. Email cooldowns remain effective when switching between immediate and daily delivery. Email previews show at most 25 incidents with the full eligible count. Missed daily windows combine into one catch-up email. Provider retries are bounded; a lost provider acknowledgement can result in a duplicate email.