This note explains the difference between raw events, detection logic, and alerts. The goal is to stop these terms from blending together and to make investigations more structured.
Official Microsoft Sentinel incidents view showing how detections are surfaced to analysts as alert-driven investigation starting points.
Why this matters
blue-team work depends on reading signals correctly
a lot of confusion comes from mixing up “what happened” with “what was detected”
understanding this flow makes SIEM tuning and alert triage much easier
Environment / Scope
Item
Value
Topic
event-to-alert flow
Best use for this note
understanding detection pipeline basics
Main focus
event, rule, alert
Safe to practise?
yes
Key concepts
Event - a single recorded activity, such as a log entry or telemetry record
Detection - logic that evaluates events and decides whether they are suspicious enough to flag
Alert - the resulting signal raised by that logic
Noise - alerts that fire often but do not help investigation
Mental model
Think about the flow like this:
flowchart LR
A["raw event"]
B["detection logic"]
C["alert"]
D["triage decision"]
A --> B
B --> C
C --> D
This means:
not every event becomes an alert
the quality of the alert depends on both the event and the detection logic
a noisy alert does not always mean the event source is bad; sometimes the rule is weak
Everyday examples
Example
Event
Detection
Alert
Failed login activity
failed authentication logs
threshold or pattern match
possible brute-force alert
PowerShell execution
process creation event
suspicious command-line rule
suspicious PowerShell alert
Port scan behaviour
many connection attempts
scan detection logic
potential recon alert
Common misunderstandings
Misunderstanding
Better explanation
”The alert is the evidence”
the alert points you towards the evidence; the underlying events still matter
”If a log exists, it should always alert”
events need logic and context before they become useful alerts
”A false positive means the source is useless”
often it means the detection needs tuning
”One alert equals one incident”
alerts can be weak signals, duplicates, or part of a bigger story
Verification
Check
Expected result
Events are visible
raw telemetry exists in the platform
Detection fires when expected
test event matches the rule
Alert contains context
enough detail exists for triage
Tuning improves quality
signal-to-noise gets better over time
Pitfalls / Troubleshooting
Problem
Likely cause
What to check
No alert from expected test
missing log, parser issue, or rule mismatch
telemetry, rule logic, field names
Too many alerts
rule too broad
thresholds, exclusions, event volume
Alert lacks useful detail
poor enrichment or weak fields
event contents, mappings
Investigation feels random
event, alert, and detection roles are not clearly separated
pipeline mental model
Key takeaways
events are the raw facts
detections are the logic applied to those facts
alerts are the resulting signals that humans still need to evaluate