3 ms·
Also, never set jobs to run at midnight (00:00) as nobody will be able to tell what day it is. Set it to 00:01 or something. And tbh, don't run jobs on the hou
by gadders 1y ago
Also, never set jobs to run at midnight (00:00) as nobody will be able to tell what day it is. Set it to 00:01 or something.
And tbh, don't run jobs on the hour anyway. Everything kicks off then. Set stuff to run at 01:45 or 02:15 or something instead.
(None of these suggestions are time change related)
- tetha 1y agoIn general I try to use odd times for cronjobs. Backups starting at XX:13, analysis scripts at XX:23, data exports at XX:42 and so on. This simplifies the question of "Why does my system go whack at 23:23? Oh, wait".
- kibwen 1y agoWith enough precision in your timestamp, you can base-10 encode arbitrary binary data and shove it in your nanos for debugging.
- ksenzee 1y agoThis is a great tip. One of our QA engineers noticed recently that a particularly difficult-to-reproduce bug was affecting records saved at :21, which is when a particular cronjob hits. Without that extra info we’d probably still be scratching our heads over it.
- gadders 1y agoThat's a good idea.
- deleted 1y ago[deleted]
- ericpauley 1y agoHonestly haven’t seen 00:00 cause confusion outside of “dog ate my homework” scenarios. If you’re using 12h clock then clearly it’s a bigger issue.