CONTEXT: Some alert types such as Long-running queries, Job Failure or Error Log Entries can trigger very frequently under certain circumstances.

PROBLEM: This causes a large number of alert emails to be sent, and the only way to ascetain that all these alerts are the same is to view the details screen for all of them.

EXAMPLE SOLUTIONS
• Group similar alerts in the alert inbox
• Raise alerts not on individual events, but on these events happening a specified number of times
• Mention identifying information sooner: e.g. directly in the alert inbox
• Suppress query-based alerts for specific databases (e.g. deadlocking 3rd party vendor databases)
• Have a "quick config" workflow that exludes the current lot of similar alerts without us having to write any regular expressions or other complicated config mechanisms
• When an alert configuration is applied, provide the option to close affected alerts.

CONTEXT: We want to see the bigger picture arising from the data presented in SQL Monitor.

PROBLEM: Currently you can't pull together a report in the SQL Monitor UI, and the monitoring database is not particularly accessible. We need reports against:
- The metrics shown in the analysis graph
- The top queries and waits
- The alerts raised over time
- Server configuration and SLA

EXAMPLE SOLUTIONS:
- Provide reporting scripts against the monitoring database
- Privide a BI interface against the monitoring database
- Priovide richer data-export functionality in the UI
- Provide a report designer in the UI (perhaps allowing for regular reports to be sent)

CONTEXT: I expect my system to slow down during routine maintenance tasks, which often leads to false postitives for performance-related alerts (long-running queries, High CPU...) in SQL Monitor.

PROBLEM: While I could configure a maintenance window where alerts don't get raised, this would also suppress operational alerts (e.g. Machine unreachable, Job failed) - these are still relevant while maintenance is in progress

EXAMPLE SOLUTIONS:
• Allow to configure maintenance times for individual alerts
• Change maintenance window behaviour so that operational alerts are still active during maintenance

What do you think about these solutions? Got another idea? Let us know in the comments!

CONTEXT: In SQL Monitor, you can configure alert behaviour down to the object level (such as the Database or the Job level). This is useful e.g. when we have specific databases with different backup policies to our global configuration, since we can specifiy "special rules" for individual databases.

PROBLEM: It is counterintuitive how to do so, and many people don't spot the left-hand drilldown navigation - this makes you think that you can only configure on the global and the server level! Also, when we have created an override, it's easy to forget so causes surprise when we change the global configuration and the "special" database's behabviour doesn't change.

EXAMPLE SOLUTIONS:
• Autoexpand the left-hand side navigation, draw attention to it
• Add Disks, Jobs and Databases as child-elements to the left-hand navigation
• show the configuration hierarchy when editing alert settings. Highlight levels where overrides exist. Allow to apply new configuration to multiple levels simultaneously

What do you think about these solutions? Got another idea? Let us know in the comments!

CONTEXT: Some counters displayed by SQL Monitor is extremely spiky. SQL Monitor scales its graph such that the any spike fits on the y axis

PROBLEM: If there is one extreme spike, all the other data gets scaled such that it's very close to the x-axis, making any patterns in the data hard to see.

EXAMPLE SOLUTIONS:
• allow to manually zoom into the y axis
• allow extreme spikes to be beyod the drawing area of the graph (still with some indicator of how high the spike is)
• have an option to show the graph on a logarhithmic scale

What do you think about these solutions? Got another idea? Let us know in the comments!

This alert already has the options to exclude queries (via RegEx) based on the process name or SQL commands/objects used. I miss a similar option for excluding queries based on the user running the query.

An example: let's say you have a job that runs SSIS job steps using a proxy->credential->dedicated domain user. The SSIS packages run loads of SQL queries, some taking a long time - but that might be expected and OK (let's say the job is a nightly ETL process for a DW). Without excluding queries based on that user (simple but effective!) you could get a whole lot of long-running query alerts, which can't really be intercepted by the existing two filtering options (at least not good/easy enough).