Stop suffering with
generic alerts
for SQL Server

Chart of SQL Server CPU consumption (maximum and average) between the specified dates. Identify utilization spikes, correlate with environment events, and verify whether the server is operating near the critical 85% threshold.

Generated by:

Chart of the PLE (Page Life Expectancy) counter over the period. PLE indicates how many seconds data pages remain in the buffer pool without needing to be read from disk. The higher the value, the better the performance. Sharp drops indicate memory pressure.

Generated by:

Chart showing the number of active connections to SQL Server over the period. Useful for identifying connection spikes, excessive idle sessions, or abnormal application behavior.

Generated by:

Chart of the total number of records in the Whoisactive log table over the period. Helps understand the volume of activity captured in SQL Server and identify moments of peak workload.

Generated by:

Chart of the pending I/O counter in SQL Server over the period. High pending I/O indicates a disk subsystem bottleneck that can cause widespread slowness. Essential for correlating latency with storage issues.

Generated by:

Chart of the available physical RAM on the server over the period. When available memory is low, SQL Server pressures the buffer pool, reducing PLE and causing more disk reads, degrading overall performance.

Generated by:

Chart showing the count of queries that took longer than 3 seconds during the period, along with their average duration. One of the most important indicators for identifying high-latency periods without having to analyze each execution individually.

Generated by:

Chart of the TempDB data file growth over the period. Frequent growth indicates excessive TempDB usage by queries, sorts, or temp tables, which can significantly impact overall SQL Server performance.

Generated by:

List of queries with the highest execution time during the period, captured by Whoisactive. Quickly identify optimization candidates without having to manually search through logs or DMVs.

Generated by:

List of SQL Server Agent jobs with the longest execution times during the period. Essential for monitoring maintenance routines and detecting performance degradation in scheduled processes before they cause impact.

Generated by:

Chart of the wait types that most impacted SQL Server during the period. Wait stats are the primary tool for diagnosing slowness — they pinpoint exactly where the database is waiting for resources: CPU, disk, locks, or memory.

Generated by:

Additional reports available for day-to-day environment analysis:

Database growth:

Table growth:

Index fragmentation (frequently requested by ERP companies in performance tickets):

Statistics validation (up-to-date statistics are more important than defragmented indexes):

As we can see below, the email itself already shows the reason the log is stuck (in this case, missing log backup — "Log Reuse Wait" column with the value "LOG_BACKUP"). It also shows which disk holds the log and the available free space, so you can feel reassured or concerned when you receive this alert.

We also show how much the log will grow and whether it is limited (to see if it is growing quickly or slowly, which helps a lot). The first pieces of information the DBA would need to log in and discover are already provided in the alert. DBA productivity and hour savings ($).

Still in the email, we have a chart to make it easy to visualize how the disk that holds the log file is being consumed — whether it is running out quickly or slowly. No log alert tool on the internet brings this information.

Since one of the most common problems can be a missing log backup, the alert also shows when the last log backup of the FULL Log database was taken. One less thing the DBA needs to check (more productivity).

We also show the queries that have an open transaction consuming the log so the DBA can analyze and find the responsible party to decide whether to kill it or not. The DBA would have to dig through their scripts to find which query shows who is consuming the most log — then run it. In Power Alerts, the insert that was filling the Log already appeared automatically.

We also show what was running at that exact moment with a whoisactive snapshot. You can see again the insert filling the log.

Finally, we can also see the alerts-per-day chart helping us identify the history of this alert. If too many alerts are coming in per day, we need to try to do something to reduce them.

We can also identify if there is a specific time of day when the alert fires most often, helping find the culprit routine.

We also create a monthly email with instance information to be used in case of disaster as documentation about the environment's state before any incident.

This helps reinstall the environment without change impacts — extremely helpful in disaster recovery scenarios.

Creation of a daily environment Checklist with charts to send instance information daily and help in analysis and comparison of information across different periods.

We use it frequently for quick environment reviews or to compare values between two distinct dates.