Scheduled Scripts Not Running

This was addressed a few times now by Ian specifically. He had stated that there are some known issues there with recurring scripts that were being investigated, and that the first priority was getting the database migration from Heroku to AWS completed so we could get the proper telemetry to allow us to hone in on specifically what might be going on there. That migration completed a little over a week ago, and they are now actively going through the telemetry to investigate further.

There are no additional updates at this time, but we will update folks on progress there as things move forward.

Same here, haven’t been able to rely on my scheduled scripts for about 8 months now. Same “Pending Engineering” ticket. This prompted me to start evaluating Ninja and Atera, but I do NOT want to start all over again. Ninja seems to be a fantastic RMM, but I’m not wild about its ticketing system, and it has no PSA or invoicing. Ninja comes with Teamviewer and they would save me enough on Sentinel subscriptions (over Pax) that my cost was $0.85/agent. There are a lot of things to like about Syncro, but no bug I’ve reported has ever been fixed, and I feel like development moves glacially. I have a dozen ideas for improvements but feel like if I cannot even get bugs fixed, there is zero chance I’ll get even minor improvements added.
In an attempt to get my assets to reboot properly, last weekend I wrote an alert based maintenance system, with a maintenance window and day defined on each asset (and default defined in each customer record). Essentially, every 15 minutes a polling script runs on each asset (whether online or offline). That script checks the current time, asset uptime, and maintenance window. If the asset is in the maintenance window, a “Reboot Window Open” alert is written. There is an Alert Remediation that fires on that alert and triggers a Syncro: Reboot. All 25 of my hypervisors (and therefore their VMs) rebooted last Friday am for the first time in 8 months.
This was a ton of work and I’m very unhappy with Syncro right now, but at least my reboots are executing now.

It does appear to be increasing in frequency. One of our RDS which is supposed to reboot nightly hasn’t automatically rebooted in 3 days. I have 6 daily scripts on this particular machine and I’m seeing days where nothing runs and a lot where only 1-3 run. That’s a pretty high failure rate.

I was hoping things would get better with the migration to AWS, but they only seem to have gotten worse since then.

I was excited to see that there is now a Known Issues section on the forums, but very perplexed and disappointed that this isn’t in the Known Issues section. How can anyone take your Known Issues section seriously if this one isn’t in there?

Being able to schedule scripts and have them run reliably is the most important thing in Syncro for me, and if it can’t do that, then I really have to question why I continue paying for a tool that isn’t doing one of its most core functions.

I (and apparently many others) have been very patient in giving Syncro time to make progress on this issue. I didn’t complain about the most recent price increase of Syncro, thinking it will help to give them the resources needed to solve this problem. But I keep noticing that scripts aren’t running on schedule. Not just running late (which I could live with), but not running at all. And I have to keep spending time checking on things and running scripts manually. It’s wearing me down and it makes me look bad to my customers when I fail to live up to what they’re paying me for, because Syncro is failing to live up to what I’m paying them for.

So, please, open an Known Issue on this already. Shift some resources to work on this problem. Hire or assign someone to manually invoke all the scheduled scripts that are getting missed. Do something to show us that you’re taking this seriously and that you understand how important it is to the people that use it. :broken_heart: :boom: :face_with_symbols_over_mouth:

1 Like

I, like many others, have a support ticket open for this issue. The rep it’s assigned to is giving off major “thinks customers were born yesterday” vibes and is suggesting things just for the sake of trying things. While they did say they are still looking into it, they do not even seem to acknowledge it’s a known issue others have reported - I am instead being told my policy folder structure is what’s likely at fault, and that “consolidating everything into one policy may provide a workaround” (so basically, for each of our dozens of customers, spend hours creating unique single policies for each customer with no flexibility, all machines in the same folder level - that is the solution I was given to recurring scripts not running due to “conflict”).

Look, I’m no genius myself, but when your customers are in IT, you can’t B.S. your way through a technical problem like this that is so obviously not related to policies (as I explained when I tested by scheduling scripts directly on the devices - not by policy inheritance - and they still did not run).

There is either a failure of management to provide support the resources they need to keep customers informed on known issues, or a lack of ticket review so extensive that support feels comfortable B.S.-ing their way through tickets. Regardless of who’s at fault, we need to get to where support is always provided a clear and concise “known issues” section so they can communicate a standardized message on the status of said issues, rather than waste our time with proposed fixes that are irrelevant. I don’t know who can enact change over there, but when I say that not even Comcast nor AT&T gave such bad-faith filler troubleshooting steps in my years working with them, I hope that is a wake-up call for the person with any power to organize the support team. You can buy a lot of time to fix tough system issues just by having support be informed, honest, and competent about it.

So true. Surely one could reasonibly expect that a known issues section would contain all the known issues?
Curious if is there is anything stopping any one of us from creating a known issue post.
Would @Andy or @ian.alexander get upset if we did?

My impression was that migration to AWS was only finally completed 1 week before Xmas. I reckon, lets give SyncroMSP some more time to shift those resources about.
Hopefully the fact that Scheduled Scripts are not running reliably is considered by SyncroMSP to be the major and serious defect in the SyncroMSP platform that we in weeds in MSP land feel it is.

Back in September we were told this:

But we’ve seen little (if any) substantial information on progress being made on this problem since then.

For many of us, this is one of the most important features of the platform, and we’ve seen no improvements, or even mentions of any progress being made on it in over 3 months now.

Can we at least get an update? And why isn’t it in the Known Issues section?

EDIT: OK, my bad… There was an update on October 24th.

And having just reviewed script histories on a bunch of assets, reliability of recurring scripts has actually gotten worse since the migration to AWS was completed in December.

@SBT maybe they are investigating the complete replacement.
I have a vague recollection that that Ian said in a video that the final Syncro processes (but didn’t define what that was) to move over was in the week before Xmas during the maintenance period discusses in this link.
Important Maintenance Part 2 Notification - 12/17/22 - Announcements - Syncro Support Community (

Yep, it is hugely important for me to. They have to fix this, otherwise all other features are not worth staying with Syncro.

1 Like

I’ve taken the initiative of staying up at 3AM for one of our clients’ scheduled weekly server reboots that depends on the Syncro scripting. What I found was that the script stays in Pending status at the scheduled run time, but eventually disappears off the schedule altogether - possibly after the expiration time. It’s good to know that there is some understanding of the nature of the problem, in that it is not actually getting scheduled, though the GUI is showing we’ve scheduled it.

This was interesting though: In the short window between the GUI’s shown scheduled start and expiration time, I decided to run a completely different on-demand script on the machine - success! It not only ran, but nudged the pending scheduled script to run as well. Almost like the scheduler “re-processed” data that had been sent to it unsuccessfully, and that the schedule wasn’t lost altogether - just not processed fully.

Not sure if this is of any help for a workaround, though. Running some completely innocuous script e.g. one that does ‘ipconfig’ and prints the output, for the sake of dislodging the pending script that didn’t start, would be great - but it, too, would have to be scheduled in order to be of any use for recurring scripts that aren’t running. But maybe, in some comical way, layering a dozen “filler” scripts, each with a low % success rate, to run 5 minutes after the one you want to run, raises the overall chance of success. :sweat_smile:

Soon after my last reply, I went into my policy that had the scheduled scripts, changed the device language, saved, changed it back, and saved again. I saw the full sync on one of the assets. Since then, my daily reboots have been happening, and the other scripts are running again. Not sure if this will help everyone, but it helped me.

I have tried this and am hoping my issue will be resolved. but currently 90% of my agents do nor reliably run scheduled scripts.

I’ve not tried the trick that @Jimmie mentioned, so I don’t know if it helps, or if it has continued to work for him since the time he posted that.

My recurring scripts are still hit or miss (with a lot more misses than I care to deal with) most days. There might have been 1 or 2 days in the last couple weeks where all important scripts ran by themselves.

There is a Known Issue about this now:

But not many people chiming in with red dots to indicate they are impacted by the issue.

I just finally marked the red dot on there, the issue was only posted about 12 days ago but has been an ongoing thing for a very, very long time. I completely forgot to go in and mark a red dot, so thanks for the link and reminder.

I have a ticket for this problem that I opened because Support told me that is how I would get updates and would know when it is resolved.

Ticket #00164109 has a status of “Pending Engineering”. I have made several notes on the ticket requesting an update but have heard nothing.

I know they have made several changes in an effort to resolve this problem.

I received an email telling me I should not expect direct updates because it is known issue and the “information is out there.” I think it came from a post in this forum.

Well, I haven’t found any information stating the problem is resolved. It is my opinion, they have failed.

They failed to fix the problem.
They failed to provide my ticket updates as they said they would.
They have failed to acknowledge any of the emails I sent using the link in the email I received from Ian Alexander with product updates. Here is what it says in the email: “Feel free to reply to this email or reach out to me if you have any questions. :blush:
Don’t bother they won’t reply.
I am tired of spending my time working around the problems in syncro. This month I received emails for three days in a row about expiring contracts. It also created 3 tickets for each expiring contract. More to clean-up. I still find endpoints with a webroot status of “matching to customer” once in a while. At least I know what to do to fix it. Too bad Syncro can’t figure out how to handle it.

I just tried to create an invoice from an estimate, and it isn’t working properly. I opened a ticket and now I will have to call support. Oh joy!

Am I upset… YES!
should I have written this post? Probably not. But I did.

1 Like

@ian.alexander mentioned today on the webinar that they found the problem, which is related to the “scheduler” and they are building something to completely replace it. No timeline given.

1 Like