Feature Idea: Is there an API for "Monitor Downtime"?

It looks it is still a feature request … any plan to include it in the one of the next releases?
It is a requirement for integration with our CD system: we want to set a monitor downtime anytime we need for deployment, but without API any automation is not possible

@paolo.dellarocca1 - Thanks for posting your use case. I don’t know where this sits on the roadmap, but I’ll get your +1 and use case added for you.

This would also assist our CI/CD pipelines. I want to be able to set Monitor downtime just before I push a release so that I do not get alerts, any update on this request?

Hey @MWilliams3 - you could use the GraphQL endpoints to set Muting Rules - which will disable notifications for the Alert conditions you set. Such that you do not hear about monitor failures that you expect.

Muting rules differ from maintenance windows in that, the monitor will still run, and will still fail. Alert incidents will still be created, so you have the full context of what happened during your release while the condition was muted. But while all that is happening, you will not receive notifications until you unmute the conditions.


1 Like

We really need the ability to schedule a downtime (maintenance window) via an API. Without it we cannot fully automate our CI/CD pipeline as we will trigger alerts during a deployment.
Needing to schedule a downtime manually defeats the purpose of using an automated CI/CD pipeline.

We need something as simple as a start downtime now at the beginning of the deployment and stop the downtime now at the end of the deployment.

The muting suggestion is not a proper solution to the problem unfortunately.

1 Like

Hey @christofer.gendreau - Can I ask for clarification on why Muting Rules is not suitable for you?

I’ll get your +1 added for this feature request, but, I’m curious if there’s a way to make Muting Rules work for you in the meantime.

So as I understand it, a muting rule just mutes notifications but the alert still occurs, which would affect our SLAs.

Next, It would seem to be a maintenance nightmare to continuously need to keep the muting rules updated as we add/remove hosts, synthetics, alerts, etc… If we could just tell NR through an API to disable/enable all alerts without needing to know the id’s, host names etc, then we would not have to maintain the list of what we want to disable/enable.

However, admittedly, I am not very familiar with the Muting Rules and using NerdGraph so there may be a way to handle what I want and I just need to dig in more. That being said, a REST endpoint to handle all of this seems to be the most appropriate way to use maintenance windows.

So, if there is a way to mute all monitors and alerts on an account AND have them not affect our SLAs, I would be very interested to understand that.

You’re right! Muting rules allow the incidents to still take place, they just remove notifications.

This is, as far as I understand it, a design decision made to ensure users can still see the effects of work completed during the muted period. Though, if your SLAs are driven by number of incidents/violations, I can totally see why this would then be a challenge for you.

As for maintaining a list of all entities to mute, that can be worked around. As my colleague Sean pointed out here:

Based on Sean’s example you can see how to target all policies, but you can adjust that to target all conditions in a particular policy, depends on how your policies/conditions are set up.

This is all great feedback though, so thank you for that! I’ll get your thoughts added in for the REST endpoint for Synthetics Maintenance Windows.


Thank you for the possible, temporary workaround for silencing all alerts at once. This is a step in the right direction. We would however, still prefer the ability to enter a true maintenance window on demand. I will continue to monitor the site for further communication on the subject.

1 Like

No worries! Thanks for the detailed feedback, it’s super helpful for us to get that back to the product teams! :smiley:

Hi there, do you know if it is possible to set a duration for a muting rule? I would like to be able to create a muting rule that lasts for 10 minutes. This would be a safeguard for the rule to be auto removed in case something terrible happens in the build pipeline that causes the pipeline to fail before the call to delete the muting rule is executed.

1 Like

Not yet! Scheduling muting rules to enable / disable at pre-set times is on the roadmap, but, that functionality is not there yet.

Only just noticed the replies. Muting rules won’t work for us as we use the synthetic statistics in reporting against our uptime. Having alerts trigger but muted would lower the overall percentage and look bad.

1 Like

Thanks for that clarification @MWilliams3 - I know you mentioned you’re hoping to integrate into your CI/CD pipeline with this. If you are able to trigger an API call via your deployment tooling, it may be better then for you to disable the monitors and re-enable afterwards. With the monitors not running, they won’t fail, and your statistics shouldn’t be impacted.

Again, not ideal, an API for monitor downtime would absolutely be better for you - but maybe that can work for you for now.


I work for a large NR customer, we have thousands of NR synthetics and regularly need to add downtime windows. We have automation tooling for most tasks but this remains one of our dark areas where we have to manually add downtime during maintenance tasks, which is both time consuming and error prone. It would be a great value-add if this feature was implemented.

1 Like

Thanks for adding in your use case @jessup - this kind of info is crucial in our feature ideas for the development teams to understand demand for these features. I’ll get this added internally for you :smiley:

At last review this feature was not accepted to be added to the roadmap. This request has been closed.

Why was this feature not accepted? There seems to be substantial interest. It is a very common use case that one would want to trigger a Monitor Downtime from deployment scripts so their SLA numbers are not affected. I’m honestly surprised this did not have an API at launch and I’m shocked this was not accepted and was closed.
Please reconsider this feature!


if this feature is now acceptable via API, why so many people are requesting this? this does not make any sense! Create Monitor Downtime for having the correct SLA is almost a must-do for all of us here requesting this feature. Unfortunately, I have to say that Synthetics API is poor and needs to be reviewed carefully because people are using more and more that module in the system.

Another important thing to take into consideration is that we have to create and pay for full users to leverage the ability for people in our organization to control Synthetics and using API and scripts, we could have more budget available to spend in better use of New Relic, not paying by user licenses that will be less important than having the ability to use the Logs module and storage logs there.

1 Like