This might be caused by Jetpack overwriting the event schedule.
You might want to contact Jetpack about this and see what they say. In addition, the minimum allowed event schedule in WordPress is ten minutes, so an event that is scheduled to run every five minutes won’t work correctly anyway.
I’ve sent them an e-mail also. I’ll update here if / when there’s a reply.
If there are 2 Jetpack crons running every 5 minutes (theoretically) on 5 sites hosted on a VPS, it seems the likely culprit to going over allotted RAM. But I’m just a user and not so familiar.
In addition, the minimum allowed event schedule in WordPress is ten minutes, so an event that is scheduled to run every five minutes won’t work correctly anyway.
I believe that this is in relation to the scheduling of single (one-off) events – so if a single (one-off) event is scheduled at time T and you try to schedule another single (one-off) event that is _exactly_ the same within (T +/- 600s) then that request to schedule the event will be ignored (although theoretically you could do so by directly manipulating the cron array in the options table). So note that includes trying to schedule an additional event within 600s before or after the existing scheduled event. If the event is given different arguments then the restriction does not apply so the restriction is easily circumvented should you wish to do so.
This does not apply to a repeating schedule event (like the jetpack cron) for which there is no minimum schedule period. In this case the cron queue only ever contains a single instance of the scheduled event as it is the WordPress Core functionality that schedules the “next” instance when the “current” instance is executed. In the jetpack case (or any other repeating event), when the current instance is triggered to run WordPress will “unschedule” the current instance and schedule a new instance (technically it reschedules first and _then_ unschedules the current event) at some time in the future taking into account how overdue to run the task might have been when it was actually triggered. So effectively WordPress will try and schedule the next instance relative to when it should have last run rather then when it actually did run which of course stops “drift”. Note that it will not schedule in the past – so, for example, with a schedule like every 5 minutes if the task was overdue by 7 minutes then the next instance would be scheduled in three minutes time and not two minutes in the past (or at least that is how it should be).
