No Email Notification for triggered alert

Hi Saiyad  

the symptom pattern (no email on New, but email on Closed/Resolved, and Exchange trace shows SCOM never even attempted the “New” send) almost always means the “New” subscription never evaluated as “true” long enough, while the “Closed” one did.

The top 3 root causes to validate (in this order):

1.    Notification delay (“bake time”) + fast auto-close or property change

SCOM subscriptions can be configured to delay sending until the alert’s properties/criteria remain unchanged for X minutes. If the alert is raised and then closes or changes (severity/priority/resolution/custom fields) before the delay expires, the “New” notification won’t be sent. Microsoft documents this behavior explicitly. This matches your story perfectly: the issue is fixed “a few minutes later”, and only then you get the Closed mail.

What to check

• Open the New subscription → Channels step → confirm whether there’s a Delay configured.
• On the alert: right-click → Properties → History and note timestamps for Raised vs Closed and any intermediate updates (severity/resolution state changes).
• If ClosedTime - RaisedTime < Delay, you have your explanation for management.

Management wording (fact-based)

• “The ‘New’ notification is configured with a delay. The alert auto-resolved/changed state before the delay elapsed, so SCOM correctly did not send the ‘New’ email; the separate ‘Closed’ subscription still triggered.”

2.    The alert did not actually meet the “New” subscription criteria at raise time

Even if you think the subscriptions “match”, subtle criteria differences can break only the New path:

• Resolution state at creation might not be 0/New (some MPs or integrations set custom resolution states quickly).
• Severity/priority can change quickly if the alert is monitor-based and configured to match monitor health, which Microsoft also calls out as a reason notifications don’t fire when delayed.
• Group/class/source scoping: if your subscription scopes to a group/class and the alert source is a watcher/partner object, the “New” one may not match while “Closed” (with broader criteria) does. Microsoft documents watcher/replication-partner source as a common reason for “no notification”.

What to check (fast)

• Compare the actual alert fields at raise time: Source, MonitoringObject, Rule/Monitor, Severity, Priority, ResolutionState.
• Temporarily simplify the New subscription criteria to the bare minimum (e.g., only “Resolution state = New” + severity) to prove it’s a criteria mismatch.

3.    Notification processing latency / load on the Notifications Resource Pool

If the notification workflow runs late (busy MS, services under load), the alert can move from New → Closed before the engine evaluates it, so the New subscription never matches when finally processed. Microsoft explicitly notes notification delays can happen under load because notification workflows run in the Management Service.

What to check

• Health of Notifications Resource Pool and the “Alert Notification Subscription Server” object.
• On every pool member: Event Viewer → Applications and Services Logs → Operations Manager around the incident time (look for subscription/channel workflow warnings/errors).

A practical troubleshooting flow (what I’d do in order):

Step 1 — Prove whether “delay + fast close” is the cause

1. Pick one missing “New” incident and record:
   • Raised time, Closed time, repeat count
   1. Record the Delay configured on the New subscription (minutes).
   2. If the alert lifetime is shorter than the delay → done (that’s your root cause).

Step 2 — Verify it wasn’t an “update of an existing alert” instead of a true new alert

If the alert is monitor-based, SCOM typically maintains one alert per monitor/instance while unhealthy; repeats update the same alert (repeat count increments). In that case, you may only get one “New” email ever (depending on your design), and later you’ll only see the closure. (This is a common operational trap with monitor alerts.)

Check

• Is the AlertID the same across “multiple malfunctions”?
• Does the RepeatCount increase instead of generating a fresh alert?

Step 3 — Run a controlled reproduction test (removes guesswork)

Create a temporary “Test – New Alerts (No Delay)” subscription:

• Criteria: minimal (ResolutionState=New; optionally severity)
• No delay
• One recipient (you)

Trigger an alert that stays active for 10+ minutes.

Interpretation

• If New mail is sent: your pipeline is fine; your real subscription logic/delay is the issue.
• If New mail is not sent: then look at global notifications settings, notification account/profile, pool health, and event logs.

(For SCOM notifications building blocks—channel/subscriber/subscription and prerequisites—Microsoft has the canonical checklist.

I hope I was able to help.

Regards,

Stoyan

"If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."