With many specialist monitoring tools, organizations rely on the equally specialized knowledge of a relatively small team of administrators because they are the only ones who can interpret the data these tools provide and understand how to act on it.

For organizations that need to monitor a large and expanding population of SQL Servers, many of which are highly available, this becomes problematic; it's inevitable that an increasing proportion of server supervision will need to be done by an operations team who, while skilled and resourceful, haven't the specialized knowledge of an experienced DBA. Therefore, SQL Monitor is specifically designed to account for this broad range of skills in its users. The data it provides is accessible and doesn't assume prior knowledge, with a real attention to embedded "expert assistance", throughout the tool.

It collects all the required machine, SQL Server and database metrics, query and process details over time and then presents, at the right moment, only the relevant metrics, along with simple graphs and summaries that will give even the less experienced investigator a reasonable clue as to the general category and possible cause of the problem. It can also directly monitor the impact of application deployments, making it much easier to tie recent system changes to changes in SQL Server behavior, and it can automate incident response workflows, automatically raising tickets for high-severity alerts. 

This makes it an ideal tool for DevOps collaboration. DBAs and developers need to be "on the same page", particularly when there's an incident that needs an urgent fix. If DBAs use one tool, while developers have a separate view of what is going on, it makes collaboration and problem solving harder. For developers, there is nothing to install; the DBA can simply grant developers access (read-only if desired) to the diagnostic data for the servers with which they work. Further, if the monitoring service is extended to the development and test servers, then feedback between Devs and DBAs can start much earlier, with the latter helping the team to improve their query design and performance, or advise on potential security issues, long before it comes time to deploy the changes to production.