SQL Server Event Monitor – Real-Time Monitoring and Email Alerting for Hundreds of SQL Server Instances Simultaneously
SQL Server Event Monitor is a lightweight, portable, and highly efficient multi-threaded application—distributed as a single executable file - designed to monitor hundreds of SQL Server instances simultaneously. It leverages fully customizable, user-defined T-SQL queries (sample included) to collect precisely the data you need.
Its power lies in a simple yet flexible text-based configuration system, enabling you to:
- Define target SQL Server instances,
- Set custom monitoring intervals,
- Fine-tune a wide range of operational behaviors.
Additionally, SQL Server Event Monitor is SQL Server version-aware: it automatically detects the version of each target instance and executes the appropriate version-specific query, ensuring compatibility and optimal performance across SQL Server 2008 through SQL Server 2025 (and beyond).
Download from Google Drive: https://drive.google.com/drive/u/1/folders/1_Xy5GCTbpwSO218eJ-rOWoSb3VBoXast
Updated: October 2025
With SQLEventMonitor, you can:
- Send real-time email alerts
- Log events directly into a SQL Server database for dashboards and analytics
- Easily adjust monitoring parameters on the fly
All of this is presented in a simple and intuitive text-based interface, designed to make your operational tasks effortless while providing deep insights into your SQL Server environment.
Email Alerting: To complement the process eco-system, an intelligent PowerShell automation script is included for real-time alerting. As soon as new events are captured and written to the SQL Server repository, the script can trigger highly configurable email notifications.
| figure #1: Sample email alert processed by the PowerShell Script |
Administrators can easily control email behavior via a text file - from choosing which servers to monitor, which events to alert on, and even applying suppression windows to prevent repeated alerts for the same issue.
The result: a lightweight, flexible, and scalable SQL Server monitoring solution that puts you in full control.
Download Link:
Download SQLEventMonitorQuick Start
- Download and unzip the package (it also contains sample queries).
- Run the executable for the first time – this will automatically create all required supporting files.
- Edit configuration settings in "event_config.txt".
- Add SQL Server instances to monitor in "event_server.txt".
- Create the alert repository table by executing the script in "event_table_script.txt" on your target SQL Server.
- Configure monitoring queries in "event_query.txt". You may use the supplied predefined queries, adjust them, or write your own.
- Run the executable again – it will begin collecting SQL Server diagnostic data for alerting purposes.
- For more details, refer to the comprehensive usage guide provided below.
Updated Version (October 2025):
The updated application is now version-aware, meaning it can execute different T-SQL queries tailored to specific versions of SQL Server instances.By default, the application uses the generic query file event_query.txt, which is compatible with any SQL Server version. This file is applied to all instances listed in event_server.txt unless a version-specific override exists.
If a version-specific query file is present, the application will use it instead for the corresponding SQL Server version. The naming convention for these files is:
- event_query.txt — Default (used for all versions if no specific file exists)
- event_query-10.txt — SQL Server 2008
- event_query-11.txt — SQL Server 2012
- event_query-12.txt — SQL Server 2014
- event_query-13.txt — SQL Server 2016
- event_query-14.txt — SQL Server 2017
- event_query-15.txt — SQL Server 2019
- event_query-16.txt — SQL Server 2022
- event_query-17.txt — SQL Server 2025
The application determines the SQL Server version of each instance at runtime and automatically selects the most appropriate query file based on the mapping above. If no matching version-specific file is found, it falls back to the default event_query.txt.
Permissions and Authentication
- Authentication
- SQLEventMonitor supports only Windows Integrated Security.
- SQL Authentication is not supported.
- Execution Account
- The Windows account under which the SQLEventMonitor process runs must have:
- Read and Write permissions on the target event repository database.
- VIEW SERVER STATE permission on each monitored SQL Server instance.
- Any additional permissions required by the specific diagnostic queries defined in "event_query.txt".
- The Windows account under which the SQLEventMonitor process runs must have:
- Notes
- Permissions may vary depending on the monitoring queries you implement.
- It is recommended to run SQLEventMonitor under a dedicated service account with only the required permissions for security best practices.
Configuring "event_config_sql.txt":
The file event_config_sql.txt defines the core settings for how and where collected SQL Server event data will be stored, as well as how often servers are checked.
TARGET_DATABASE_SERVER=<EventWritingSQLServerInstance>
TARGET_DATABASE_NAME=dbSQLEvent
TARGET_SQLTABLE=tblSQLEvent
# How often to execute queries (in seconds)
NEXT_SERVER_CHECK_SEC=120
# How often to read event_server.txt to add/remove server
NEXT_SERVER_REFRESH_MIN=30
# Number of shared threads to execute queries against all servers.
MAX_CONCURRENT_THREADS=50
VERSION_CHECK_TIMEOUT_SEC=30
QUERY_EXECUTION_TIMEOUT_SEC=45
# Number of log files and size of each file
MAX_LOG_FILES=10
MAX_LOG_FILE_SIZE_MB=25
# Logging activities
# If set to NO, will log essential information and errors
WRITE_TO_LOG=NO
- TARGET_DATABASE_SERVER: The SQL Server instance where all collected events will be written.
- TARGET_DATABASE_NAME: The database name on the target server where events are stored.
- TARGET_SQLTABLE: The table name within the target database that stores event records.
- NEXT_SERVER_CHECK_SEC: The default interval (in seconds) between checks of each monitored server.
Configuring "event_server.txt"
The file event_server.txt defines the list of SQL Server instances to be monitored. Both default and named instances are supported. There is no limit to the number of servers that can be added – monitoring is virtually unlimited.
Format: Duration|SQLServerInstance
Parameter Details
- Duration (optional)
- The frequency (in seconds) at which query in "event_query.txt" will be executed against the target server.
- If omitted, the default value from NEXT_SERVER_CHECK_SEC in "event_config.txt" will be used.
- SQLServerInstance (mandatory)
- The SQL Server instance name.
- Can be a default instance (e.g., SRV001) or a named instance (e.g., SRV001\SQL2017).
- IP addresses and server names are both supported.
Additional Guidelines for "event_server.txt":
- One server per line: Each line must represent exactly one SQL Server, with or without a duration value.
- Separator: Use the pipe character | to separate Duration and SQLServerInstance.
- Comments: Use # at the beginning of a line to comment out a server.
- Apply changes: After modifying this file, restart SQLEventMonitor.exe for the changes to take effect.
- Logging: Check the \logs\ folder for detailed runtime information and error messages.
Example:
- 120|WIN251 -> Run query every 120 seconds against this default instance
- RDP80\SQL2022 -> Use global default interval for this named instance
- 30|WIN252 -> Run query every 30 seconds against this default instance
- WIN253 -> Use global default interval for this default instance
- 60|192.168.0.230 -> Run query every 60 seconds against this named instance
| Figure #2: Running SQLEventMonitor.exe on the command prompt |
Notes on Running as Windows Service:
Use NSSM (https://nssm.cc/) to create a Windows Service. Ensure that the service account has the necessary permissions to access both the monitored SQL Server instances and the event repository server.
Configuring "event_query.txt"
The file event_query_sql.txt contains the diagnostic T-SQL queries that SQLEventMonitor will execute against all listed SQL Server instances.
Key Requirements:
- The file may contain one or more SELECT statements combined using UNION ALL.
- Each SELECT statement must include the following columns:
- SourceName
- EventSubject
- EventType
- MessageText
- If these columns are missing or misnamed, the query will fail.
Notes
- Several production-ready queries are provided a separate "event_query_sql.txt" to detect common SQL Server issues so that you can start quickly.
- These queries are designed with backward compatibility in mind.
Supplied Alerting Events in the diagnostic query:
The provided alerting queries will capture and generate the following events:
- Blocking detected
- Long-running active session detected
- Long-running idle transaction detected
- AG replica health issue detected
- tempdb space usage
- Database log usage alert
- tempdb latch contention
- Memory utilization
- Plan cache usage
- Pending I/O requests
- AG replica lag
These events cover a broad range of performance, availability, and resource utilization scenarios commonly encountered in SQL Server environments.
You are encouraged to add, update, or adjust queries in event_query_sql.txt to fit your unique operational and monitoring requirements.
Structure Example
Sample Structured Query Example:
Quick Start – Email Alerts:
- The PowerShell script SQLEvent_Monitor_Mail.ps1 sends email notifications based on the criteria defined in "eventAction_EventSubject.txt".
- Before using the script, update the following parameters:
- Alert Repository server
- Table name
- SMTP server configuration
- Recipient email addresses
- The script is designed to prevent duplicate or repetitive alerts. When run for the first time, it creates a file named "eventAction_LastEventID_sql.txt" and records the current MAX(ID) from the alert table.
- If you skipped running the script for a period and new records have accumulated, you may delete "eventAction_LastEventID_sql.txt" to avoid sending old alerts.
- Each time the script starts, it:
- Reads the latest MAX(ID) from the alert table.
- Updates or recreates "eventAction_LastEventID_sql.txt" with the new value.
- Processes and sends email alerts only for new records after the MAX(ID).
Customizing Email Alerts for SQLEvent_Monitor_Mail.ps1:
The configuration file eventAction_EventSubject_sql.txt controls how and when email alerts are sent.
File format: Servers | EventName | Duration (in minutes)
Parameter Details
- Servers (mandatory)
- Use * to include all servers, or specify one or more server names separated by commas.
- EventName (mandatory)
- Must exactly match an event name defined in event_query_sql.txt.
- Duration (optional)
- Defines a suppression window (in minutes).
- This determines how frequently the script can send alerts for the same event.
- Without a duration (*|EventName), alerts are sent every time the event occurs.
Examples of Customization:
- *|Blocking detected:
- Monitors SQL blocking across all servers and sends alerts whenever blocking is detected.
- *|Blocking detected|10:
- Monitors SQL blocking across all servers, but applies a 10-minute suppression window, preventing duplicate alerts within that time.
- SRV2700,SRVFIN\SQL2019|Blocking detected:
- Excludes blocking alerts for these two servers.
- Alerts will still be sent for all other servers.
- SRV0012,SRV0HR\SQL2022|Blocking detected|15:
- Monitors blocking for all servers, but applies a 15-minute suppression window only to these two servers.
- SQLSRV314|tempdb space usage detected:
- Suppresses tempdb space alerts permanently for this server.
- HR234,FIN450\SQL2017,SQLSRV314|AG replica lag:
- Suppresses AG replica lag alerts for these three servers only.
Sample eventAction_EventSubject_sql.txt:
Quick rules:
- * in server field = applies to all servers.
- No duration = permanent suppression.
- With duration = rate-limiting (alerts only after N minutes).
- Multiple servers can be listed with commas.
- # skip the line to evaluate and to send email alert.
- Subject match is substring/LIKE, not exact.
Conclusion:
I have worked on the Windows and SQL Server platform for many years, and during that time I have not found a lightweight, easy-to-configure tool that consistently delivers the desired results. While I am familiar with many commercial solutions, I often find them unnecessarily complex, slow to respond, prone to missing critical alerts, and demanding excessive hardware resources due to heavy data processing.
The tools I share here are the result of my personal initiative and hobbyist development. They have been running successfully in live production environments across 300+ servers for many years without a single issue. I hope you will find them equally useful in your own work. Thank you.