The most detail my NDA permits me to get into is that our most recent failure was that the systemd cron replacement gets in a state where it refuses to ever schedule a scheduled task and that the systemd folks were like "aw, shucks" about it.
FWIW, I'm generally a fan of systemd. That's a pretty minor issue in the grand scheme of things and it's not really "mysterious" -- the behaviour was consistent but didn't line up with the documentation.
In my experience, almost every time I hit an issue with systemd, it's when I'm interacting with it at a (relatively) low level. e.g. Monitoring / controlling units via D-Bus. There is theoretically enough documentation to do that, but it's often incomplete or ambiguous and you're left trying to figure out systemd's behaviour via experimentation.
But as I said, this isn't _really_ a dig against systemd. Even if monitoring service state transitions via D-Bus is finnicky, it's a heck of a lot easier than the alternatives with busybox init or whatever.
An example from my company - sometimes on a few of the many thousands of identical devices in field something fails due to bug or hw failure. After recovering the device we get the dump of all info we deem interesting, including all logs and journals. In a small but not insignificant numbers of such archives the journal has multihour gaps in the logs. And they are gaps, so there are logs before the gaps and after. I think we never succeeded to reproduce or fix this issue in the lab, and relied on duplicating logs to the file on the device fylesystem (not optimal due to storage size and wear of the ssd memory).
PS: personally I like systemd more that the script mess which preceded it. But the are some outstanding issues with it to be improved.
