Hi @rtaylor2 - Unfortunately, since our alerts evaluation system happens on a minutely basis when the data comes in infrequently anything over 60 minutes gap will need to use the proposed workaround suggested below:
Relic Solution: Extending the functionality of NRQL alert conditions beyond a single minute
In addition, the alert condition is based on a NRQL alert condition using count(). New Relic used to insert synthetic zeroes as a result for some queries, but ever since Streaming Alerts for NRQL conditions was introduced, synthetic zeroes are no longer inserted (the rules for when they were inserted was obtuse and opaque, so now you get exactly what the query returns).
Take a look at this article, which will explain why count() and uniqueCount() will never return a value of 0. The article also goes into a couple possible solutions depending on your use-case – these are new features which were also released with the Streaming Alerts Platform.
Depending on the situation you may need to set up a Loss of Signal (LoS) for the same duration as the threshold, and configure it to Open new "lost signal" violation when met. This will result in violations opening when the query stops returning numeric values and drops to 0/NULL or set up a Loss of Signal (LoS) for the same duration as the threshold, and configure it to Close all open violations when met. This will result in violations which close automatically, as you’d expect them to.
There is one caveat, which is covered in the article I linked as well: there needs to be a signal to lose, in order for LoS behavior to kick in. That is, there must be a numeric data point that then drops to NULL. Currently, given the data coming in right now, adding a LoS setting to this condition will not result in a violation opening – there would need to be at least one evaluation window with a non-NULL value first.
