@harry97 many comments in this thread already suggest that as one of the - arguably better - alternatives anyway.
This is generally related to your original motives for choosing Meteor as your framework. If your motivations have been around simplicity, single platform, single codebase, mongodb, meteor data system and/or package system, as well as factoring in single vs multiple instances, dedicated vs embedded workers etc then your window of options naturally narrow down.
That still does not negate npm-installable options, just that such options have not been built with Meteor in mind so there indeed is merit in a quest to find a meteor friendly - if not meteor native - solution.
That being said, I’ve used Kue, Bull and Agenda on some past and recent Meteor codebases as an alternative to Synced Cron and they’ve fared well for their use cases.
On node-cron specifically though, that package does not provide you any persistence or locking mechanism for multi-instance deployments so you need to figure out horizontal scaling yourself. It is perfectly fine for single-instance use cases and obviously much more robust than naive setInterval based concoctions.
Edit: Cloud (aws/google) message/pubsub solutions are also quite worth investigating as they are much easier than they sound by their lingo. Also, there are some cron-as-a-service options out there if all you need is time based jobs.