I understand the use case. it's been requested before, but the challenge is there aint one correct behaviour that suits all. Not that I can see anyhoo.
Consider a few examples:
Example 1: Daily schedule
Schedule:
Every day at 09:00
Node-RED starts at 11:30.
Questions:
- Should Cron Plus trigger immediately because today's 09:00 event was missed?
- Should it do nothing because the event is already in the past?
- Should it only trigger if startup occurred within a configurable period after 09:00?
- How would it know whether the scheduled action was already performed before shutdown?
- What if user doesn't want or need this behaviour?
If the scheduled job feeds a dog, triggering late could be useful.
If the scheduled job sends an email, triggers an alarm, or charges a battery, firing late may be bad.
Example 2: Repeating interval
Schedule:
Every 10 minutes
Node-RED starts at 09:08.
Should it:
- wait until 09:10?
- fire immediately?
- fire immediately only if less than ½ the interval has passed since the previous schedule?
- attempt to "catch up" on missed executions? (How would it know?)
Different users will want different options.
Example 3: Solar schedules
Schedule:
Sunrise -30 minutes
Today's event occurred at 07:15.
Node-RED starts at 11:30.
Should Cron Plus emit the event immediately because the startup time falls within the "daylight" period?
Or should it not, cos the sunrise event itself has already passed by more than 4h?
Again, both behaviours are reasonable depending on the application but I bet there 5 more expectations users would want!.
Example 4: State versus event
Suppose a flow uses:
Sunrise -30m => turn pump ON
Sunset +30m => turn pump OFF
User might need the correct state restored after a restart.
However, Cron Plus has no way of knowing:
- whether the pump is currently on,
- whether another flow or user action changed the pump state (and doesn't want node-red to alter that just because it restarted (because it was deliberately/manually overrode today)
- whether the earlier event successfully executed
Determining the desired state is imo a state management problem not a scheduling problem.
The main problem
The scheduler can not easily determine:
- whether missed events should be replayed,
- how many should be replayed,
- how old is "too old",
- whether replaying them is safe,
- whether the user actually wants the resulting action to happen (this time)
Because of all that 
a startup trigger feature becomes a complex set of rules and edge cases ( different users will deffo want different behaviour)
IMO, in most cases it's better for the flow itself to decide what to do on startup by querying Cron Plus for the last/next event and along with other related state, have flow logic that does (or doesn't) do the thing!
So you know, I have mulled this over quite a few times (and I haven't even mentioned a tenth of the considerations I've made in my noggin on this matter) - but never reach a satisfactory set of rules/UI that would work for all users (and not be overly complicated). If you have a solid idea I'd love to hear it?
