1585 views

Inactivity Monitor not triggering events as expected for incident matching conditions 

 

Overview
Inactivity monitors are commonly used to send notifications about new incidents that may have been delayed in processing or missed. For multiple reasons, notifications may not be generated accurately while monitoring incidents that would expectedly match the inactivity filter conditions set. This unexpected behavior may be observed on only some of the incidents that match the conditions. Others are included in the inactivity trigger events as expected.

 

Environment
All SN current releases.

  

Solution
  1. Check the conditions that have been set on the incident tasks by navigating to System Policy > SLA > Inactivity Monitors

  2. Verify that the sys_trigger events processing is not stuck on the instance for outage or performance issues. 

  3. Investigate the timeline of inactivity events generated by navigating to System Logs > Events

  4. Filter on Name = incident.inactivity

    The Parm1 field contains the sys_id of the incident record that triggered the event. 
In order to troubleshoot misfiring conditions, it is helpful to understand some relevant inactivity monitor properties. 
  • An inactivity monitor cannot be retroactive; it does not track incidents that were created before the latest update to the inactivity monitor itself, even if all conditions are met. So, when an inactivity monitor is saved, it begins monitoring from that moment forward. Even if pre-existing incidents were in the inactivity triggering states, they are not picked up by the newly set monitor. This is because the monitor creates a scheduled job for each record that meets the criteria. Since the old incidents were updated before the monitor was created, no job was ever created for them. 

  • When an incident is created or updated, the system looks at the inactivity monitor definitions and creates a sys_trigger event with a next_action time set to when the inactivity monitor duration is hit. If a further update occurs that causes a reset of the inactivity monitor, the sys_trigger record next_action time is updated. If time passes, the sys_trigger record executes, creates the inactivity.incident event record, and creates a new sys_trigger record with the new next_action time set. 

  • If multiple inactivity monitors are created that may have their conditions met for a given record, only the one with the lowest given order is triggered. 

Additional troubleshooting steps

Following are additional troubleshooting steps that can be used when email notifications configured on inactivity monitor events are not being sent. 
  1. Check that the triggering action occurs (the incident is Closed). 

  2. Verify that the event is placed in the event queue.

    A business rule may be responsible for adding the event to the queue. 

  3. The scheduled job named events process should normally run every 30 seconds and process all events in the queue. 

  4. A sys_email record should be created only if the event was tied to a notification. 

  5. The scheduled job named SMTP Sender should normally run every two minutes and send all email messages currently in the outbox.
     
  6. The related email message should be placed in the Sent folder.

Article Information

Last Updated:2015-05-02 11:47:12
Published:2014-08-29