Glenn; You cannot tell "how often the Datawedge" application is "stopping" using an MSP Collection Metric, per se.  Doing that reliably would require constantly checking to see if the process is running, on a pretty high duty cycle, and counting when it was not running, then waiting until it was running again, before again checking for when it was not running.  You could build code to do that, and deploy it with MSP, but it would need to be carefully constructed to avoid causing significant impact to the device and other applications. What you CAN do with an MSP Collection Metric, is measure the amount of CPU time accured by the Datawedge process during a given sample interval.  If you collect that metric every 5 minutes, it will tell you how many CPU seconds Datawedge ran during that period.  Since there are a total of 300 possible CPU seconds that can be used by all processes collectively in 5 minutes, you may be able to tell over time when Datawedge was running, when it stopped, and when it was not running, but looking at the history of its CPU time usage.  Of course, that assumes that Datawedge uses significant CPU time (at least one second out of 300) whenever it is running, even if it is not doing anything.  If you are scanning, that may be true, but if you are not scanning, it may be more difficult to tell "idle" from "not running". To do the above, you need to create a custom Collection Metric.  The easiest way to do that is to Copy an existing one and then modify the copy.  What I usually do is copy CpuTime.MSPAgent and change the name of the .EXE in the collection string.  Then you need to add the new metric to a category or create a new category and then create a collection request that collects that category from one or more devices at the desired interval.