It's unfortunate that only a SELECT query is supported for SQL Query monitoring.
Given that you can have monitors for Duration, Result Check, and Record Count, stored procedures would be a very valuable addition as they can certainly output a result set of columns. In many cases, executing a stored procedure is the only way to get some information you would want to monitor, such as using sys.xp_readerrorlog to read entries in the SQL Server error logs. If you need to monitor Service Broker in SQL Server, executing that procedure is the only way to obtain that information.
With support for stored procedures, it would also be beneficial to support the use variables (an assignment). Supporting stored procedures without supporting variable assignment would force the usage of dynamic SQL execution- making the script more difficult than needed.
I can understand that forcing only a SELECT statement provides the ability to pre-validate a specified column name in a Result Check monitor, but what we give up is not worth that pre-validation. You are already handling exceptions if the script errors.
Here is an example script that queries the SQL Server error logs I would like to monitor:
declare @startDate nvarchar(100) = Cast(DateAdd(minute, -30, GetDate()) as nvarchar);
0 /* Current log file */,
1 /* SQL Server Log (non-agent) */,
N'[auth].[Handle', N'' /* Search text (x2) */,
@startDate /* Start Date */