Turning Critical Windows Events into Immediate Notifications with a Script

Windows records almost everything that happens to it in the event log, and buried in that constant stream are the handful of entries that genuinely demand attention: a disk reporting predictive failure, a critical service crashing, an unexpected shutdown, a security event that should not have occurred. The problem is that these critical entries sit in the same log as thousands of routine ones, unread until someone goes looking, which usually happens only after the trouble they warned of has already caused visible damage. A notification script reverses this, watching for the specific events that matter and pushing an alert to a human the moment one is recorded.

The motivation is the gap between when an event is logged and when a person learns of it. The event log is a goldmine of system data, tracking everything from minor notices to critical errors, but its value as an early warning is wasted if no one reads it in time. Marrying the log with a script that monitors for specific events and triggers actions closes that gap, so that a critical entry no longer waits passively to be discovered but actively reaches out, turning the event log from a forensic record consulted after the fact into a live alerting source.

Identifying the Events That Actually Warrant an Alert

The first and most important task is deciding which events deserve a notification, because alerting on too much is as useless as alerting on nothing. The event log is overwhelmingly full of routine, informational entries, and a notification system must filter down to the small set that genuinely signals trouble. This means identifying specific events by their log, their source, and their numeric identifier, the three coordinates that pinpoint a particular kind of occurrence among the multitude.

Events are organized into logs, with the classic system, application, and security logs joined by many specialized logs under the applications and services hierarchy. Within a log, each event carries a source identifying the component that raised it and an identifier denoting the specific event type, and it is this combination that a monitor keys on. Knowing, for instance, that a particular identifier from the service control manager means a service terminated unexpectedly lets a monitor watch for exactly that condition and ignore the surrounding noise.

Discovering which events to watch is itself a useful exercise, and the tools make it tractable. The event-reading cmdlet can list all logs on a system and their record counts, and can filter a log down to specific identifiers, which lets an administrator explore what gets logged and settle on the handful of events worth alerting on. The aim is a deliberate, short list of critical event signatures, each chosen because its appearance reliably indicates something that needs human attention.

Reading Events with Get-WinEvent

The modern tool for querying the event log is a cmdlet built for exactly this, capable of reading both the classic logs and the newer applications-and-services logs with powerful filtering. For a notification script, the key is to retrieve only the events of interest, filtered by log, identifier, and time window, rather than pulling everything and sifting afterward. Filtering at the source keeps the script fast even on logs that hold enormous numbers of entries.

$since = (Get-Date).AddMinutes(-10)
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id      = 7034
    StartTime = $since
}

This retrieves any service-crash events from the system log in the last ten minutes, which is the natural pattern for a monitor that runs on a short interval: each run examines only the window since the previous run. The filter approach is efficient because it asks the system for just the matching events, and the same structure extends to multiple identifiers or multiple logs by adjusting the filter, letting one query cover several critical event types at once.

The cmdlet returns rich event objects whose properties carry the details an alert should include, the time, the message text, the source, and event-specific data. Pulling these out lets the notification convey not just that a critical event occurred but what it said, which is the difference between an alert that prompts action and one that merely prompts a trip to the event viewer. A monitor that extracts and forwards the event's own message saves the responder the first step of investigation.

Triggering Notifications the Moment an Event Appears

There are two architectures for connecting an event to a notification, and they suit different needs. The polling approach runs a script on a schedule that queries for critical events in the recent window and alerts on any it finds, which is simple and reliable, catching events at the next poll after they occur. For most monitoring this is entirely adequate, since a delay of a few minutes between a critical event and its alert is acceptable.

The event-driven approach instead attaches a task directly to an event, so that the notification fires the instant the event is logged rather than at the next poll. Windows supports this natively through the task scheduler's ability to trigger on an event, and through the event viewer's option to attach a task to a specific event. When the matching event occurs, the task scheduler launches the script immediately, giving near-instant notification for the events where every minute counts.

$trigger = New-ScheduledTaskTrigger -AtStartup
# Event-based triggers are defined via the task's XML subscription,
# binding to a specific log, source, and event identifier.
$action = New-ScheduledTaskAction -Execute 'powershell.exe' `
    -Argument '-NoProfile -File "C:\Scripts\notify-critical.ps1" -EventRecordID $(eventRecordID)'

The event-driven model has a powerful refinement: the triggering event's own details can be passed to the script, so the notification carries the specifics of the very event that fired it. By configuring the task to expose the event's record identifier and channel to the script, the script can fetch that exact event and include its details in the alert, producing a notification about the specific occurrence rather than a generic warning that something happened. This makes immediate, event-driven alerts both fast and informative.

Composing and Delivering an Informative Alert

An alert that merely says a critical event occurred forces the recipient to go digging, so a good notification carries enough context to act on. The message should name the event, the machine it occurred on, the time, and the event's own description, so the responder grasps the situation from the alert alone. Including the originating computer is essential when the same monitor runs across many machines, since the responder must know immediately which system raised the alarm.

$evt = Get-WinEvent -FilterHashtable @{LogName='System'; Id=7034} -MaxEvents 1
$body = "Critical event on $env:COMPUTERNAME`n`n"
$body += "Time: $($evt.TimeCreated)`n"
$body += "Event ID: $($evt.Id)`n"
$body += "Message: $($evt.Message)"
Send-MailMessage -SmtpServer 'smtp.example.com' -From Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.' `
    -To Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.' -Subject "[CRITICAL] $env:COMPUTERNAME event $($evt.Id)" `
    -Body $body -Priority High

Email is the classic delivery channel, sent with high priority so the alert stands out, but the same logic can drive whatever channel the team actually watches, a chat platform, a ticketing system, or an entry in a central monitoring tool. The task scheduler itself can also send an email or display a message directly as an action, though a script gives far more control over the alert's content, which is why scripting the notification usually produces a more useful result than the scheduler's built-in actions alone.

Whatever the channel, the alert should be tested before it is trusted, because an alerting path that has never been observed to work is an assumption rather than a safeguard. Forcing the script to run once and confirming the notification actually arrives, ideally by right-clicking the scheduled task and running it on demand, verifies the whole chain end to end. If the test alert arrives, the real one will too; if it does not, the time to discover that is now, not during the incident the alert was meant to catch.

Deploying the Monitor Across Many Machines

A notification script that protects one machine is useful, but in a fleet the real value comes from deploying the same watch everywhere, so that any machine raising a critical event reports it the same way. Because the script, its watched-event list, and its scheduled trigger are all expressed in code, the identical setup can be pushed to every machine, bringing the whole estate under uniform monitoring rather than a patchwork of individually configured systems. This uniformity is what makes the alerting trustworthy: every machine is known to be watched, and every alert follows the same format.

Distribution itself can ride on existing management infrastructure. The same event-triggered tasks can be deployed through group policy or a management tool, so that adding a new machine to the fleet automatically brings it under the monitoring without anyone configuring it by hand. This removes the drift that otherwise creeps in when each machine is set up individually, where one server ends up watching events another ignores, and a critical event on the unmonitored machine slips by unnoticed.

A consideration unique to fleet-wide alerting is the risk of correlated storms: an event that affects many machines at once, such as a network outage or a bad update, can trigger a flood of near-simultaneous notifications from across the estate. A mature setup either aggregates such alerts so that one consolidated message describes the fleet-wide condition, or routes them through a central system that can recognize the common cause, rather than dispatching hundreds of identical alerts. Anticipating this keeps a single widespread incident from drowning the responders in noise at exactly the moment they most need clarity.

Avoiding Alert Fatigue and Storms

A notification system lives or dies by the trust its recipients place in it, and nothing erodes that trust faster than too many alerts. If a critical event recurs rapidly, a naive monitor will fire a fresh notification for each occurrence, burying the inbox and training everyone to ignore the alerts entirely. The defense is to suppress repeats, alerting once when a condition first appears and then staying quiet about the same ongoing condition until it resolves, rather than announcing every individual occurrence.

Equally important is restraint in what qualifies as critical in the first place. An alert list padded with events that are merely informational or routinely benign dilutes the signal, so that genuine emergencies arrive amid a clutter of cried wolves. Keeping the watched-event list short and genuinely critical, each entry chosen because its appearance reliably means trouble, is what keeps every alert meaningful. A monitor that alerts only on things that truly matter is one whose alerts are actually read.

The discipline extends to acknowledging that some context only emerges over time. An event that is alarming in isolation may be routine in a particular environment, and tuning the alert list as experience reveals which events are genuinely actionable is an ongoing process rather than a one-time setup. The goal throughout is a system whose every notification earns its interruption, because the moment alerts become noise, the critical one will be dismissed along with the rest.

What Scripted Event Notification Ultimately Delivers

The deeper lesson is that the event log's value as an early warning depends entirely on someone learning of a critical entry in time to act, and the only way to guarantee that is to let a script do the watching and the alerting. A disk warning or a service crash logged at three in the morning should not first be noticed during the next day's troubleshooting; it should already have summoned a response while the problem was still small. Scripted notification closes the gap between logging and awareness.

A well-built notification system watches only the events that genuinely matter, reads them efficiently through the modern event cmdlet, chooses polling or event-driven triggering to match how fast an alert must arrive, composes notifications rich enough to act on, delivers them reliably to where they will be seen, and guards against the alert fatigue that would render it useless. Each piece is modest, but together they transform the event log from a passive archive into an active guardian.

In the end, turning critical events into notifications is how an administrator stops watching the logs and lets the logs watch the system. Instead of periodically combing through entries hoping to catch trouble early, there is a script that surfaces the few entries that matter the instant they appear, with enough detail to respond. The small effort of identifying the critical events and wiring up their alerts repays itself the first time a notification arrives in the night and a problem is met in its opening minutes rather than discovered, grown and entrenched, the following morning.