[FEATURE] Add a "per‑event" notification option (vs. the batched per‑cycle summary) for deadlocks & blocking

Which component(s) does this affect?

Problem Statement

Summary:

Deadlock and blocking alerts currently aggregate all recent events in the window into a single notification (one tray/email/webhook card with N detail blocks, and the detail list appears capped). There's no way to receive one notification per event, which teams need for per‑incident tracking (e.g., one Azure DevOps ticket per deadlock). Downstream automation can't split the batched payload reliably because the per‑event details are flattened into repeated name/value facts rather than a structured array.

Current behavior:

BuildDeadlockContextAsync / BuildBlockingContextAsync (Lite MainWindow.xaml.cs:1668,1739; Dashboard equivalents) build one AlertContext from GetRecentDeadlocksAsync/…Blocking(hoursBack: 1) and send a single alert (TrySendAlertEmailAsync).
The card shows Current Value = N but lists only a few events (apparent Take(3) cap), so high‑volume incidents are truncated.

Proposed Solution

Proposed:

A notification mode setting (global and/or per‑server): Summary (current default) | Per‑event (one notification per deadlock/blocking event).
In Per‑event mode, a configurable max‑per‑cycle cap (e.g. default 10) to prevent floods during a storm, with a final "+X more" summary if the cap is hit.
Each per‑event message should carry a stable per‑event identifier/fingerprint (the involved objects — ties into the "stable dedup fingerprint" request) so downstream dedup/ticketing is per incident.
Apply to deadlocks and blocking first; consider extending to long‑running query.

Keep: Summary as the default; Per‑event is opt‑in. Existing cooldown/gating still applies per event.

Use Case

I want to be able to create an issue about particular problem and if the message is grouping and not showing all errors, I can miss something.

Why it matters:

One ticket/notification per incident is impossible: the webhook delivers one payload with multiple events as repeated Victim SQL/Processes facts — not parseable into distinct events without fragile heuristics.
Truncation hides events beyond the cap.

Alternatives Considered

No response

Additional Context

No response

Merge pull request #1142 from erikdarlingdata/feature/1140-alert-dedu…

The grouping + per-incident fingerprint half of this is implemented and merged to dev (so it's in tonight's nightly); the per-event delivery mode itself is the next step.

In the nightly now:

Identical blocking relationships are grouped within a notification — the same chain no longer repeats once per sample. You get one entry with the true occurrence count and a wait range (min–max) instead of the same chain shown 3× (your follow-up on [FEATURE] Add a stable, machine‑readable dedup fingerprint (and involved‑object list) to alert payloads - esp. deadlocks & blocking #1140).
The silent Take(3) cap now surfaces the true total ("+N more") rather than hiding events.
Each grouped incident carries a stable per-incident fingerprint (the [FEATURE] Add a stable, machine‑readable dedup fingerprint (and involved‑object list) to alert payloads - esp. deadlocks & blocking #1140 Dedup Key) — your point 3, which is the key piece for per-incident ticketing in your Logic App.

Still to come (the headline ask here):

The Summary | Per-event notification mode toggle + the configurable per-cycle cap. The grouping above is the foundation it sits on, so this is a focused follow-on.

So you can already test per-incident dedup/counter behavior against the grouped fingerprints in tonight's nightly with your Logic App; one-notification-per-event delivery will follow. Leaving this open to track that piece.

Merge pull request #1144 from erikdarlingdata/feature/1141-per-event-…

Update: the per-event delivery mode itself is now implemented and merged to dev too — so it'll be in tonight's nightly.

New setting (Settings → Alerts): Deadlock/blocking delivery: Summary | Per-event, plus a max per cycle cap (default 10). Default stays Summary.
In Per-event mode, deadlock/blocking alerts send one notification per distinct incident (each carrying its [FEATURE] Add a stable, machine‑readable dedup fingerprint (and involved‑object list) to alert payloads - esp. deadlocks & blocking #1140 Dedup Key + involved objects) instead of the batched card. If a cycle produces more incidents than the cap, a final "+N more" notification carries the remaining fingerprints so nothing is silently dropped.
Global for now; a per-server override is the one remaining follow-up.

So you can flip on Per-event mode in the nightly and have your Logic App open/track one ticket per incident, counting recurrences by the Dedup Key.

Verification update: built tonight's dev locally and confirmed the per-event delivery mode works end-to-end —

Settings → Alerts now shows Deadlock/blocking delivery: Summary | Per-event with a max per cycle cap (default 10), defaulting to Summary. Confirmed rendering in the running app.
Full unit suite green (984 tests, incl. the new per-event split coverage); both apps build clean.

So it's good to go in tonight's nightly to test against your Logic App. The per-server override remains the one follow-up.

Merge pull request #1146 from erikdarlingdata/feature/1141-per-event-…

Merge pull request #1231 from erikdarlingdata/feature/changelog-backf…

Per-event notification mode shipped on dev: AlertNotificationMode + PerEventNotification, Settings UI in both apps, default Summary, per-cycle cap. The remaining optional per-server override is tracked separately in #1236. Closing the core request; lands on main with 3.1.0.

erikdarlingdata#1140/erikdarlingdata#1141: shared blocking + deadlock…

erikdarlingdata#1140/erikdarlingdata#1141: wire dedup fingerprint int…

erikdarlingdata#1141: per-event notification mode for deadlock/blocki…

erikdarlingdata#1141: fix per-event cards losing forensic detail + Cu…

Backfill CHANGELOG for the shipped alert fingerprint cluster (erikdar…

Add per-server override for alert delivery mode (#1236)

Merge pull request #1436 from erikdarlingdata/feature/1236-darling-de…

Phase-5: Lite forwards to the shared alert engine

Wire up per-server + per-event alert delivery mode for Darling (erikd…

Navigation Menu

Repository navigation

[FEATURE] Add a "per‑event" notification option (vs. the batched per‑cycle summary) for deadlocks & blocking #1141

Which component(s) does this affect?

Problem Statement

Proposed Solution

Use Case

Alternatives Considered

Additional Context

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[FEATURE] Add a "per‑event" notification option (vs. the batched per‑cycle summary) for deadlocks & blocking #1141

Description

Which component(s) does this affect?

Problem Statement

Proposed Solution

Use Case

Alternatives Considered

Additional Context

Activity

erikdarlingdata commented on Jun 17, 2026

erikdarlingdata commented on Jun 18, 2026

erikdarlingdata commented on Jun 18, 2026

erikdarlingdata commented on Jun 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions