I’ll chime in as well: our traffic is fairly consistent, active during the day and minimal during night (in USA) looking to utilize for alerting on traffic below a certain throughput during “active” hours
Thanks so much for sharing the details you are looking for @_mg. Those are really helpful for our engineers.
This feature is still not available outside of an API call to turn it off? How difficult is it to implement a maintenance window in NR? The majority of other tools support this functionality.
Same here. This is standard feature is in most monitoring tools (Nagios/Netsaint had it almost 20 years ago)
Can’t imagine how it is not in New Relic New Alerts by now.
We could definitely use this feature as well. We would like to put alerts on a service that monitors our sales reps, which have heavy usage during the day, but no use at all during sleeping hours. Unable to easily put an alert due to this lack of feature.
An even better idea, to emulate what some other services offer, is to offer anomaly detection, where you can set alerts based on historical pattern differences, since usage can vary quite a bit based on the time of day.
Our traffic is much lower at night than during the day. We would love to be able to set different thresholds based on time of the day. Maybe by entering start time /end time for each alert? Thanks!
Is there any update regarding this issue? I am getting lots of unnecessary maintenance alert notifications. If there is an automatic way to stop testing during maintenance hours that would be greatly appreciated. I am currently using the Keynote software as well and they have all the features implemented.
Have you tried our baseline conditions to for APM, Browser and NRQL? They will accomodate for these daily/weekly patterns.
Hi @Aliabbas_Fazal, I can update you on a few things around this area of the NR platform.
The title of this thread focuses on not receiving notifications during certain times of day. There are a few ways to approach this problem. As someone pointed out putting schedules on conditions is one way, however I’m not sure this is the best approach due to the large increase in condition configuration and ongoing management complexity it introduces.
We think modern baselines is the ideal approach to this problem. A system that models past behaviors, accommodates for trends and weekly seasons/cycles is a simpler more flexible approach to alerting on these tricker KPIs.
Additionally there are times when teams need to do maintenance on a system that will likely cause crazy things to happen to the data collected. One comment above mentioned nightly database dumps that make i/o and other measure emit wonky values during the backup. Recurring and one time maintenance windows is the solution we want to introduce for this. Basically being able to choose entities in NR and associate it with a window of time where notifications should not be sent.
It is possible to solve for this using our APIs and cron jobs today, but a native solution is really the most efficient way to do this. Defining windows like this in Alerts is high priority and I hope to be able to share some more information on this effort soon.
is this one resolved and is there a solution if so please let us know
Hi, @sgaddam: No change since @nateheinrich’s post above: metric baseline alert conditions can calculate dynamic alert thresholds based on past behavior of a metric; if you prefer to enable / disable alert conditions at specific times, you may use the REST API to do so.
Can we enable and disable newrelic-infra using API ?
Can we enable and disable newrelic-infra alert conditions using API ? because i am searching in the docs only found for APM … if am wrong please let me know. Thanks for ur previous response
Hi, @sgaddam: Yes, you should be able to use the REST API to enable or disable Infrastructure alert conditions: https://docs.newrelic.com/docs/infrastructure/new-relic-infrastructure/infrastructure-alert-conditions/rest-api-calls-new-relic-infrastructure-alerts.
I too need this for reason B
For NRQL alerts that trigger when a value is above a threshold, one workaround is to not capture values during certain hours by adding the following where clause:
where hourOf(timestamp) not in ('23:00', '0:00', '1:00', '2:00', '3:00', '4:00', '5:00', '6:00', '7:00') AND weekdayOf(timestamp) not in ('Saturday', 'Sunday') WITH TIMEZONE 'America/New_York'.
Thanks so much for sharing that workaround @hugh.j.gardiner. We really appreciate making sure that others can learn from your work!
My company could also really use a native feature to mute alerts during off-hours. We will investigate using the work-arounds listed above, but I hope to see progress on a full feature for this soon. Thank you!
Does New Relic give importance to the ideas and votes they collect? It does not seem like it …
This good idea was suggested in 2015, and despite the many votes it has obtained, so far this feature is still not available.
In my opinion this evolution should not be very complicated to implement and would be so useful !
An e-commerce site, for example, concentrates most of its activity between 8 am and 1 am. Alerts based on APM EXTERNAL SERVICE (web services calls), which make sense when the application is requested, do most of the time make no sense when it is not.
This generates false alerts, and over time, the operational tend to no longer pay attention to these alerts, at the risk of not detecting real problems.
Thank you for reconsidering the interest of the community in this feature.
I am convinced that the implementation of this feature would be very appreciated by all of us.
Thank you and regards.
Hi @olivier.roussel - We do take feature ideas seriously, and the votes on them too.
I struggle to think how many feature ideas live in the Explorers Hub, and internally too. It’s a very difficult balancing act to prioritise feature requests with respect to the current product roadmap & to customer demand.
We in the Support Team do try our best to ensure the feature ideas in the most demand get seen by the right people in the Product Team. However like I noted, prioritising this work is not easy when there’s a constantly busy roadmap.
I’m going to bring this thread to the appropriate product manager today, I’ll follow up here when we have an update to share
@olivier.roussel - I’m happy to chat some more about our processes around feature ideas if you’d like to DM me.