Alert Deduplication

Alert fatigue happens when teams receive so many notifications that important signals get lost in the noise. Sazabi uses intelligent deduplication to ensure you get notified about real issues without being overwhelmed by repetitive alerts.

Why deduplication matters

Without deduplication, a single production issue can generate dozens or hundreds of alerts as Chat detects the same problem from different angles or at different times. This leads to:

• Notification overload: Your Slack channel or inbox becomes unusable
• Desensitization: Teams start ignoring alerts because most are duplicates
• Missed signals: Genuine new issues get buried under noise

Sazabi's deduplication ensures that each distinct issue generates exactly one alert, with additional occurrences tracked as part of that alert.

Two-gate deduplication system

Sazabi uses a two-gate system to filter out duplicate alerts while ensuring genuine issues get through:

Gate 1: Heartbeat impact gate

Before creating any alert, Chat evaluates whether the detected issue has corroborated impact. This gate filters out:

• Transient errors that resolve before affecting users
• Low-volume anomalies that do not indicate systemic problems
• False positives from noisy log patterns

The impact gate uses investigation context to determine whether an issue is worth alerting on. An elevated error rate might be significant in one context but expected behavior in another (e.g., during a deployment).

Gate 2: Root-cause matching

If an issue passes the impact gate, Sazabi checks whether it matches an existing open alert. Chat performs semantic matching to identify alerts with the same root cause, even if the symptoms differ.

For example, these issues would be matched as duplicates:

• "Database connection timeouts in payment service"
• "Slow queries affecting checkout flow"
• "PostgreSQL connection pool exhausted"

All three share the same root cause (database connectivity), so they are grouped under a single alert rather than creating three separate ones.

Mute-based deduplication

When you mute an alert, Sazabi continues to apply deduplication for that alert's root cause. If the same issue fires again while muted:

• No new notification is sent
• The mute hit count increments
• The original alert remains in its muted state

This prevents a muted issue from generating noise through related alerts that bypass the original mute.

When deduplication does not apply

Deduplication is intentionally bypassed in certain scenarios:

Manual triggers

When a user explicitly asks Chat to create an alert (e.g., "create an alert for this issue"), deduplication is skipped. The assumption is that the user has a reason for wanting a new alert, even if a similar one exists.

Resolved alerts

Once an alert is resolved, a new occurrence of the same issue creates a fresh alert. This is intentional: if an issue returns after being fixed, you want to know about it rather than having it silently attach to a closed alert.

Different projects

Deduplication only applies within a single project. The same issue occurring in both your staging and production projects will create separate alerts, as these represent distinct environments that require separate tracking.

Viewing deduplicated occurrences

When multiple occurrences are grouped under a single alert, the alert detail view shows:

• Mute hit count: How many times the issue was suppressed while muted
• First seen: When the issue was first detected
• Last seen: The most recent detection

This gives you visibility into the frequency of an issue without the noise of separate alerts.