I am glad to hear my suggestion has finally made it to the top of your list. Let me know when the beta is available and I will give it a test.

Hi Dennis,

Thanks for your suggestion, I think this would improve the efficiency of researching events. I have logged this suggestion as SRP-9223

Thanks
Adam

I have been fighting an occasional Blocked Process alerts. One of the problems with researching these events is that the first event, the one causing the issue, is not the first event on the Alerts tab of Heath Monitor. Also, the emailed alerts note an Alert number, which is not displayed on the website anywhere that I have been able to find except the URL of the web page. It would be helpful to be able to sort the list of alerts by either the time the event was FIRST raised, or by the event number. This would then make the offending event show up first in the list. For now, I have to review the email stream to locate the first event.

Hi Jamie,

Thanks for the clarification. I'm beginning to wrap my head around why this nonstandard use of iCal is actually quite an elegant improvement over the RSS metaphor. I'll be interested to see how other people feel about this feature, and how popular this suggestion becomes compared to the other feedback we receive.

Just one other point Daniel, you asked:
"Would a calendar view within SQL Monitor be more or less useful than viewing the information in an iCal client?" but perhaps a better question might have been:
"Would the information in the RSS feed (which is what Jonathon originally blogged about) be more or less useful than viewing the information in an iCal client?"
Both are subscription technologies. Both require specialist client software (RSS client & Calendar client respectively).
The advantage of iCal (IMO) is that presenting the information in a calendar provides the priceless context of *when*. Furthermore, everyone uses a calendar, not everyone uses an RSS reader.
The point being, if you're providing an RSS reader then I can't really see any justification for not providing an iCal feed also.

Hi Daniel,
"In what scenarios would you like to see a calendar view of your alerts? "
Not really sure what you mean. I think the answer is "all scenarios".

"why would a calendar view be more readable than, say, a plain list of alerts?"
The beauty of subscribable calendars is that the data just 'flows' into the places that I already send my time (i.e. my Outlook/GMail calendar). "More readable" isn't really the benefit here, its simply that I don't have to go to (yet) another place to see data. The data comes to me, I don't have to go and get it.

"How would you expect the system to behave if there is a large volume of alerts? Would you still like to receive all of them?"
Yep.

"Would a calendar view within SQL Monitor be more or less useful than viewing the information in an iCal client? Why?"
Less. Hopefully my previous answer speak to the "why".

"Any feedback you could give us would be much appreciated!"
Subscribable calendars are a bit of a soapbox subject for me. For further explanation I invite you to take a read of this blog post that I wrote some while back: http://sqlblog.com/blogs/jamie_thomson/archive/2010/06/03/thinking-differently-about-bi-delivery.aspx

regards
Jamie

Thank you Jamie.

Regards,
Priya

Jonathan Allen recently blogged about the ability to view SQL Monitor alerts as an RSS feed: https://www.simple-talk.com/blogs/2013/06/04/sql-monitor-alerts-in-outlook-without-configuring-email-settings/
This is cool and all, one thing I'd also like to do is be able to view these events in my calendar (any calendar, not just an Outlook calendar).
An industry standard exists for subscribable calendars - its called iCalendar. iCalendar allows someone to expose data (any data) in a manner that allows iCalendar compliant clients (e.g. Outlook, Google Calendar, Outlook.com calendar) to consume and display that information. The beauty of *subscribing* to iCalendar calendars rather than *importing* them is that new events automatically turn up in the client. if the user has got that calendar synced to their smartphone they automatically show up there too. No work required on the part of the user. This is the power of subscription (its wonderful when it works).
Hence, my suggestion is that you expose the same events that are currently in the RSS feed in iCalendar format - thus allowing someone to view that data in their calendar and thus get the context of *when* something happened as well as simply *what* happened (which is what the RSS feed gives you).

Hope that makes sense.

note that i discussed this with Jonathan & Priya Sinha on Twitter and Priya suggested (https://twitter.com/sinha2009/status/342287315307220992) I raise it here.

Thanks a lot Andrew for the idea!

I would like to be able to filter on alerts based on time only. I want to see the alerts that are occurring on a repeating pattern. ie All the alerts between 1.00am and 2.00am over the last n days.