1 Overview
Event Log Monitor lets you watch for specific Event IDs. Define the log source and Event ID(s); then define how many times the event must occur in a given timeframe before an alert is raised or an automation is triggered.
Possible use‑cases include:
Excessive failed log‑ons
Malware detections from a security tool
Service crashes or restarts
Application errors
With highly targeted rules, you surface the events that matter and ignore the rest.
2 Creating an Event Log Monitor
Navigate to Policy -> Monitors -> Add or choose an existing Monitor Policy and choose Add new monitor.
Name – Give the monitor a name - the name is what shows in the alert, e.g. "Application crashed 5 times in the last hour"
Type - Chose Event Log
Severity – The alert priority you want to raise (Information, Warning, Error, Critical) – independent of the OS event level.
Event IDs – One or more numeric IDs (press Tab or type a comma between IDs).
Log name – Case‑insensitive channel name, e.g.
Security,System,ApplicationSource (optional) – Event Source/Provider string if you need to narrow further (e.g.
Outlook,VSS,Kernel-General).Levels (optional) – Filter on Windows event level (Information, Warning, Error, Critical, Verbose). Leave blank to match any.
Occurrences & Duration – Specify how many matching events must occur within the chosen time window before an alert is triggered.
Example:5occurrences in1minuteAuto‑resolve – Enable to clear the alert automatically once the condition is no longer met.
Automations (optional) – Select a predefined automation to run when the alert fires (e.g. disable the local account, kick off a remediation script).
Notifications (optional) – Enable if you want email notifications when the alert is created or resolved.
The rule is immediately pushed to all tagged endpoints that match the policy.
4 Example
Detect possible brute‑force log‑ons
Field | Value |
Event ID |
|
Log name |
|
Levels | leave blank |
Source | leave blank |
Occurrences | 10 |
Duration |
|
Alert severity |
|
Tip – If the rule never triggers, check that Windows Logon Failure auditing is enabled.
5 Best Practices
Be specific – Combine Event ID with Log name (and Source or Level) to reduce false positives.
Use thresholds – In our example above, a single failed log‑on is usually noise; ten in a minute deserves attention.
Pair alerts with automations – For example, run a script to disable an offending account or react in realtime to collect more diagnostics.
Start narrow, expand later – Begin with one or two high‑value rules (e.g. 1102, 1116) before adding broader coverage.
6 FAQ
Q Can I monitor multiple Event IDs in one rule?
Yes—separate them with commas or hit Tab after each ID.