Deduplication

When multiple credential leaks match the same monitor, Stealed does not create one event per leak. Instead, deduplication ensures one open event per monitor, and tracks new leaks against the existing event until you close it.

This page explains the rule and why it produces cleaner alerts.

The rule

The deduplication logic has two cases.

Case 1: An event is already open for this monitor

When a new leak matches a monitor that already has an open event:

• The leak is added to the existing event.
• The event's matched_count is incremented.
• No new event is created.
• A renotification may fire if the volume threshold is reached.

In practice: you get one event per monitor at a time, and that event grows as more matching leaks arrive.

Case 2: The previous event is closed

When a new leak matches a monitor whose previous event has been closed:

• A new event is opened.
• The new event only counts new credentials: leaks whose hash was already part of the closed event are NOT recounted.
• Notifications fire on the configured channels.

In practice: closing an event resets the slate for "what's new", but the historical credentials don't generate fresh noise.

Why this design

Without deduplication, a monitor watching a high-volume domain would produce dozens of events per day, all about the same underlying problem. Your team would spend more time triaging duplicates than acting on them.

With deduplication:

• One event per monitor at a time: the activity timeline of that event is the single source of truth for that incident
• Closing an event signals "I've handled the current set": only genuinely new credentials trigger a fresh notification afterwards
• Audit trail integrity: each event covers a defined population of leaks, identified by their hashes; the chronology is reproducible

Example timeline

Consider a monitor watching acme.com with a threshold of 5.

How "new" is determined

A credential is identified by its hash (an opaque cryptographic fingerprint computed from the username + password + target URL).

When a leak arrives:

1. Stealed computes its hash.
2. The hash is checked against:
   • The anti-replay floor of every monitor that could match
   • The hashes already counted in any open event of those monitors
3. If the hash is not yet seen by the monitor, the credential counts.

The anti-replay floor is the highest last_seen timestamp of any leak already counted by the monitor. It moves forward as leaks are tracked, ensuring an old leak that gets re-ingested doesn't recount.

Edge cases

Editing a monitor's filters

If you change the filters of a monitor that has an open event, Stealed correctly bumps the anti-replay floor so the existing event keeps tracking the new scope from that point forward. The event is not closed automatically. If the new scope is unrelated to the old one, you may prefer to close the existing event first and start fresh.

Enabling / disabling a monitor

Toggling the monitor off and on resets last_resolved_at to zero. This means a re-enabled monitor counts every matching leak as new, even if it was already known to the previous instance.

This is different from muting, which preserves state.

Duplicate detection across organizations

Hashes are scoped per organization. If two organizations watch the same domain, both see the same credentials, but the hash counters are independent. There is no cross-tenant deduplication.

What's next

• Renotification: the volume threshold that controls reminders inside an open event.
• Incident handling: how to close an event cleanly to reset the slate for new alerts.