Especially in Mx 4 the platform had some issues in recalculating the event start and execution times. There were some miscalculations in when to schedule a microflow.
In your scheduled event you have to specify the first start date of your event. Previously the platform had trouble calculating if there were to many runs. In your case you run every 15 minutes, if you set the start date/time in the modeler to 5 years ago (30-Oct-2014 09:05am) at startup the modeler will add the interval (15minutes) to that start date until it finds the next time it should run in the future.
So it would do:
30-Oct-2014 09:05am + 15 min = 30-Oct-2014 09:20am
30-Oct-2014 09:20am + 15 min = 30-Oct-2014 09:35am
until the date it finds is larger than currentDateTime.
There used to be calculation errors in here where it either froze up or came up with some really weird date months in the future.
The workaround for this used to be to bring the start date closer to today, so if you'd change the start date in the scheduled even in the modeler it might work again.
But first check the log, and try restart the server (which should start the scheduled event). If you can't find an error, or if the event doesn't start you can try my suggestion.
When for some reason the scheduled event did not finish it could be that the server needs to be restarted to run the schedule again. As Stephan mentions you need to check the log to see what happened, and in the scheduled event overview you will also see that this scheduled event did not finish.
For mission critical scheduled events I advise always to schedule multiple events. So instead of running one scheduled event each hour, schedule two events that run every two hours and seperate an hour between those two. This way when a scheduled event fails you can reset the server when it is convieniant instead of when it is necesarry.
Some exceptions can break the thread that runs the scheduled event. So be sure that your topmost microflow in the scheduled event has some form of custom error handling so no exception can 'escape' into the runtime.
When I create a scheduled event, the topmost microflow only has a call to the microflow that does the actual work. That microflow call has errorhandling set to custom with rollback so the runtime does all rollback actions. When an error is caught, log the message and stacktrace at level error (or even critical) or you would not know what happened. In your error flow, end with a normal end event, not an error event.
This ensures that the scheduled event always ends normally so the scheduler will not be harmed in any way.