I've noticed over the last month or so that occasionally some inject nodes are failing to fire?
I've a number of interval and timed interval nodes, but on more than a few occasions now I've noticed that they sometimes fail to fire. I can't quite put my finger on the issue. Nothing obvious in the logs, but it's deffo happening...
Anyone else suffering this?
Are there any other approved methods of firing a flow to a schedule with a little more surety? Maybe some sort of watchdog...?
Thanks.
cron-plus
I've seen what you say is happening but ONLY with the inject at startup and the time is too quick.
I have never seen the inject node miss a beat. However, I do recall it being mentioned a while ago. I also know that the underlying library was changed out at some point.
With that said, you will need to provide more details. Node red version. Node version. How do you know for certain the inject was missed rather than some downstream node or logic in your flow that prevented the message travelling (i.e. do you have a debug node connect directly to the inject node that outputs to console?). Do you know for certain there were no restarts? Do you know for certain there was no heavy processing in your node-red or on your server at the time?
That is something many people see but it's not really being missed. What's happening is that the event actually does happen but before your front end is ready to receive it. The inject message does fire in the back end and does do its job. The proof can be seen by adding a debug node that outputs to console.
I don't tend to notice with repeating injects where say the interval is quite short, but I have a number of weekly one shot injects, for example 07:30 on a Monday and 17:00 on a Friday that I have noticed sometimes either don't fire, or the resulting flow fails to respond.
I do have some 'on startup' injects, but can't remember having problems with these.
I can't say for sure the rest of the flow didn't have a problem, but when manually triggered they have never failed to run.
I have a number of NR instances running (all same version) and have noticed similar problems with all of them. I'll start adding some debug to console nodes as suggested, might also add some file out nodes to a csv to make it easier to track down after the fact...
Ver: 4.1.10 running in the official container.
Just offering options - the kind I've used. 
It may be hard to always be monitoring for a signal.
(Yes foreign nodes used)
Given the payload has a time/date part in the message......
The message goes into theqgate node then I can go to it and and flush, next or reset the messages.
It can be handy to help catch unattended messages for future reference.