There are numerous ways to monitor for blocking in SQL Server. One of them is a WMI event alert for the BLOCKED_PROCESS_REPORT event class. I've used that approach before, and generally with satisfaction. However, I've run into an issue on a couple of servers: the SQL Agent Alert unexpectedly stops working. When the event occurs, there is a corresponding error message in the SQL Agent log indicating a failure:
 Unable to query the alert BlockedProcess for WMI events. WMI error 0x80041032
The SQL Agent WMI event alert is configured to run a SQL Agent job that logs the blocking information, which can be analyzed later. But once WMI error 0x80041032 begins occurring, the SQL Agent job never runs. That's a problem.
Here's a look at the SQL Agent Alert and the Response. (There's a script to create it, if interested.)
Both the servers where the problem occurred were SQL Server Failover Cluster Instances (FCI). Failing over the cluster from the primary to a secondary temporarily "fixed" the problem. My guess was that rebooting the primary server or restarting the database engine service would have also worked. But I did not test either scenario as these were production systems. Other tests that I wanted to try, but didn't, included restarting the WMI service and restarting the SQL Agent service.
I would eventually discover that disabling and re-enabling the SQL Agent Alert also temporarily "fixed" the problem. Executing the msdb system stored procedure sp_update_alert also did the trick (see below). However, if I omitted the @last_response_date and @last_response_time parameters, the alert continued to fail.
EXEC msdb.dbo.sp_update_alert @name=N'BlockedProcess', @occurrence_count = 0, @count_reset_date = NULL, @count_reset_time = NULL, @last_occurrence_date = 0, @last_occurrence_time = 0, @last_response_date = 0, @last_response_time = 0
Sadly, I have not yet discovered the root cause of the problem. Every time I "fix" the problem, it comes back again later.