It sounds like you’re wanting a kind of heartbeat condition where the agent will tell New Relic that it’s still running even when no real transactions are coming through. Does that sound about right? I can totally understand the desire for this sort of monitoring and it’s something that other folks have requested too. Monitoring low throughput transactions and applications is a pretty complicated problem to generically solve!
One solution my team has used is to have a Synthetics monitor regularly hit a couple endpoints for our service’s API to keep some level of traffic coming through all the time. You can then configure a condition like @stefan_garnham suggested. If Synthetics doesn’t work as a solution for you because of architectural concerns or the service not being accessible publicly, you could even setup a cron job that would curl that endpoint periodically (once a minute works but if it’s just a curl you could even do it more often).
Another indirect monitoring solution my team uses is to monitor the error rate of something that has the service in question as a dependancy. We are responsible for the uptime of a service that is critical to consumers of our team’s services (Service A) that has some unique monitoring challenges. We settled on having the Infrastructure agent running with a Host Not Reporting condition, so we could be sure that the machine this service runs on is healthy, and we combine that with a condition targeting the error rate of a service (Service B) that we know will get a very high error rate if Service A falls over or stops responding to requests.
Other details for this are notes in our runbooks to verify that Service A is reachable when responding to pages before trying to dig too deep. The idea for all of this is that if you get paged in the middle of the night, you’ll open the runbook link included in the notification and start following those instructions. An engineer can be woke up and while their brain is trying to get a handle on what’s happening, they have a couple of quick checks to make sure the most critical pieces of our team’s infrastructure are working. If they aren’t well fire up the coffee and get to work getting them online. If they are then maybe you don’t have to shake off your sleep quite so quickly and it’s something that could get some further examination in the morning.
I realize that direct monitoring solutions are preferred, and I always strive to use them when possible. Low throughput applications and transactions are a challenging case. Right now the agents aren’t really designed in a way that makes the sort of heartbeat monitoring I think you might be asking for super easy. If that is what you’d like, let’s make sure we get this filed as a #feature-ideas:feature-ideas-alerts so that your voice can be heard. I promise that this is something you want to speak up about! It makes a difference when teams are weighing feature work and the Alerts team especially takes customer feedback very seriously. (Everyone else does too, I just have a soft spot for Alerts )