Severity: Info
Files:

• src/Servy.Core/Logging/EventLogLogger.cs lines 24-26
• setup/taskschd/Get-ServyLastErrors.ps1 line 70
• setup/taskschd/ServyFailureEmail.ps1 line 62
• setup/taskschd/ServyFailureNotification.ps1 lines 115, 145

Description:

All of the above write to Application Event Log with Source = "Servy", but they use two entirely disjoint Event ID ranges:

Consequences:

• An operator filtering Servy events by Event ID range (common practice in SIEM / WEF collectors / simple Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Servy'; ID=2000}) sees half the picture.
• Documentation of "what Event IDs Servy emits" has to list two unrelated ranges, one of which is hidden in scheduled-task helper scripts that an admin may not realize are related.
• There is no documented meaning for the specific IDs — 9901 vs 9903 is unexplained in the PS scripts; 1000/2000/3000 is generic.

Suggested fix:

Centralize Event IDs in a single source of truth (e.g. src/Servy.Core/Config/AppConfig.cs or a new EventLogIds static class) and have the PowerShell scripts read from the same list — either by generating the PS constants from the C# source at build time, or by documenting the reserved ranges in a header comment that both sides reference.

Proposed reservation (example):

• 1000-1999: informational events
• 2000-2999: warnings
• 3000-3999: errors
• 9000-9099: reserved for PowerShell helper scripts, categorized by type (e.g. 9001 = scheduled task failed to read event log, 9003 = scheduled task failed to send notification)

Whichever layout is chosen, document it and keep both code paths in sync.