In 2016, commit 05228c2 merged a systemd timer unit from OpenSuse, which was later amended by 3f3991e to reduce "trigger fuzz".

I support a number of Linux workstation users who have enormous log volumes due to audit logging and noticed high load during system bootup. Investigation led towards this systemd timer unit that can be traced back to logrotate's source repository:

# /lib/systemd/system/logrotate.timer
[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

The Persistent=true setting causes systemd to catch up with missed timers while the system was down. AccuracySec=1h does however not lead to a random trigger delay.

Quoting the systemd documentation for systemd.timer:

Note that this setting is primarily a power saving option that allows coalescing CPU wake-ups. It should not be confused with RandomizedDelaySec= (see below) which adds a random value to the time the timer shall elapse next and whose purpose is the opposite: to stretch elapsing of timer events over a longer period to reduce workload spikes.

My users will receive a packaged drop-in for the unit that amends this as follows:

# /usr/lib/systemd/system/logrotate.timer.d/randomize.conf
[Timer]
RandomizedDelaySec=1h

I'm submitting the issue in the hope that proper use of systemd timer randomization in the example unit is relevant to more people than just me. :-)