Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

Feature Idea: Manually Trigger Synthetics Monitors



Vote Now! | Manually Trigger Synthetics Monitors

  • I want this, too
  • I have more info to share (reply below)
  • I have a solution for this

0 voters

We take feature ideas seriously and our product managers review every one when plotting their roadmaps. However, there is no guarantee this feature will be implemented. This post ensures the idea is put on the table and discussed though. So please vote and share your extra details with our team.

Manually triggering monitor

Hi, I want to trigger monitor manually from synthetics website or via synthetics api. Is that possible? How can I do that?


Hi, @myildiz: I believe that Synthetics monitors always run on a schedule. You could, however, create a monitor that runs once per minute and disable it. When you want to run it, use the Synthetics API or UI to enable it for one minute, then disable it again.


This could be done but 1 minute monitor schedule exceeds our plan checks. :frowning:


Hi @philweber, are you aware of anything in the pipeline to provide more flexible scheduling capabilities for synthetics?

I’ve received requests internally for two broad capabilities around scheduling changes:

  • The ability to manually fire a monitor. Lets say a synthetic fails, the fault is resolved but we want to fire a “retest please” request (button in the web interface and an API interface would be good here)
  • Finer granularity on scheduling. Lets say an API is only available/valid during market opening hours and would return a fault code out of this window. We’d like the ability to schedule a monitor only between 08:00 and 16:30 Monday-Friday. I’ve had other requests for high-frequency testing during core business hours and a lower frequency schedule out of hours.

The second case can be worked around with silent exits in the script but this burns through 3 times as many synthetic credits as required in this example. I can see a way to use API calls to continually update the monitor schedules but this introduces a level of coupling / complexity that would be good to avoid.


Hi, @pault: Thanks for your suggestions. I teach customers how to use the products as they currently exist, so I’m not the best one to ask about what’s in the pipeline. Hopefully a member of the product team will chime in.


Hi @pault!

Thanks for the feedback you’ve shared here. I love love love getting to know what it is that our customers want to see next. I can tell you that both of the capabilities you’ve requested ARE on my radar. Unfortunately, with other priorities that my team is facing, this work hasn’t yet been scheduled. While this isn’t ideal news, I encourage you to check back periodically as our priorities can change based on customer feedback/demand.

In the mean time, I do see possible workarounds for both of your issues.

The “instant test” use case could be addressed in the way that @philweber describes - creating a disabled monitor set to 1 minute intervals then programmatically enabling that monitor via the API, letting it run, then disabling it again. It’s not a perfect solution, but might meet your needs for now.

The flexible scheduling could also be met via the API by running a chron job that updates the monitor frequency at the times that you want it to change. For example, you could have a monitor that you set to 1 minute intervals at 9am and then set back to 15 minute intervals at 5pm.

I hope these ideas help, and thanks again for all your feedback!


Hi @jmarcel - any updates on this?

The reason we want this is to be able to trigger “smoke tests” immediately after a deployment to make sure the deployment was successful.


No update right now, @thm.alex.ehlke! Please be sure and participate in our poll (above), and thanks for sharing your use case!



any updates on this one?


Nothing new to share, @MKhanna ! Feel free to add your use case for this feature in the thread! :thumbsup:


It’s kind of ridiculous that this is not yet in the UI - it’s super valuable when debugging or altering checks, and the workarounds you describe @Linds are a fair amount of work rather than add, relative to the synthetics product, a very small feature.


Selenium-based synthetics allow for doing test runs, which makes this much more simple engine not having them feel even worse.


Hi there @max.schubert - Nice to see you back. I agree that the workarounds are not ideal here. I wish that I had a timeline for implementation for you, but I appreciate your patience.


Any update on this feature?

We have a few scripted UI synthetics that we run every 30 minutes. Sometimes they fail because the site is a little slow or something external is having an issue.
I would like to be able to re-run the failing test so I can see if its working now.

I tried programatically getting the failed test details from insights, and then via the API disabling and enabling the synthetic, thinking that may make it run on enabling. But that doesn’t appear to be the case.


Hi @brett.howells - good news. You can now recheck failed monitors! More on this feature in our docs:

Let us know if you have any questions.


That is true! I have seen that button on the site.
I want to trigger this through the API. Is that possible?


@brett.howells Not currently - The only API option right now is to disable and re-enable the monitor, which will re-trigger the monitor to be scheduled. But that is not a single API call to run the monitor immediately.

I’ll make sure the team know that an API call to re-trigger failing monitors is a feature that there is some interest in. :slight_smile:



Is there a solution right now to run the Synthetics via an API?


Not yet @priyadarshini.r.kolw - Just the same workarounds mentioned above. I’ll get your +1 added here for you :slight_smile: