Events, Alerts, and Detections

Summary

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:

raw event -> detection logic -> alert -> triage decision

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

Related

• Back to Security Concepts
• What a SIEM Does
• Log Sources and Telemetry
• Basic Alert Triage