Schedules

Schedules

Note

Every timed job on a SEEDbox host, as of Oct. 2026 (main branch). The first table is what the playbook sets up. The second lists the Debian 13 timers that run next to it: SEEDbox does not manage them, but they matter when two jobs collide. Schedules stay hard-coded in their roles unless noted; this page is the inventory, so update it whenever a role changes a schedule.

Table of Contents

• Set up by SEEDbox
• Host timers (Debian 13)
• The early-morning window
• Time zones
• Adding or changing a schedule

Set up by SEEDbox

When	What	Defined in	How to change it
Daily 05:47	Watchtower checks for new images and recreates the containers that have one (with watchtower.monitor_only true, it only checks)	roles/watchtower/tasks/main.yml, WATCHTOWER_SCHEDULE	Hard-coded in the role
05:00, only when an installed upgrade needs a reboot	unattended-upgrades reboots the host	roles/hardening/tasks/unattendedupgrades/main.yml, Unattended-Upgrade::Automatic-Reboot-Time	Hard-coded in the role
Every 4 h at :00 UTC (00:00, 04:00, 08:00 … UTC)	Speedtest Tracker runs a speed test	roles/speedtesttracker/tasks/main.yml, SPEEDTEST_SCHEDULE	Hard-coded in the role. It runs in UTC because the role does not set DISPLAY_TIMEZONE (see Time zones)
Every 6 h at :00 (00:00, 06:00, 12:00, 18:00)	Scrutiny's collector reads the disks' S.M.A.R.T. data	defaults/settings.yml.default, scrutiny.cron, passed to the container as COLLECTOR_CRON_SCHEDULE	scrutiny.cron in settings.yml
At container start, then a few seconds after a file changes	Navidrome scans the music library	roles/navidrome/tasks/main.yml, ND_SCANSCHEDULE	The role sets ND_SCANSCHEDULE: "1h", but Navidrome 0.55 renamed it ND_SCANNER_SCHEDULE and ignores the old name, so there is no hourly scan
Every 5 min, counted from the container start (only with dynamic_ip: true)	Cloudflare DDNS checks the public IP and updates the DNS record when it changes	roles/cloudflare/tasks/ddns/main.yml, image default UPDATE_CRON (@every 5m)	Not set by the role: add UPDATE_CRON to its env
Hourly at :00	tinymotd rebuilds the status summary shown at login	tinymotd.timer in /etc/systemd/system, written by tinymotd's install script, which roles/tinymotd/tasks/main.yml runs	Hard-coded in tinymotd's install script

Not listed: scheduled tasks inside the applications themselves (for example the *arr, Jellyfin and Kavita task schedulers). They are set in each application's own settings.

Host timers (Debian 13)

Package defaults on a Debian 13 host. SEEDbox only installs or enables the packages noted in the last column. Run systemctl list-timers --all, cat /etc/crontab and ls /etc/cron.d to see the list on your own host: it depends on the installed packages.

When	What	Source
06:00 + up to 60 min	apt-daily-upgrade.timer: unattended-upgrades installs updates, which can queue the next 05:00 reboot	Debian, enabled by the hardening role (APT::Periodic::Unattended-Upgrade)
06:00 and 18:00 + up to 12 h	apt-daily.timer: refreshes the package lists	Debian, enabled by the hardening role (APT::Periodic::Update-Package-Lists)
Daily 06:25, Sunday 06:47, 1st of the month 06:52	cron.daily, cron.weekly, cron.monthly (when anacron is not installed)	Debian /etc/crontab
Every 20 min (:00, :20, :40)	sendmail runs its local mail submission queue (/etc/cron.d/sendmail); the sendmail daemon runs its main queue every 10 min by itself	sendmail package, installed by the hardening role
00:00	dpkg-db-backup.timer	dpkg
00:00 + up to 1 h	logrotate.timer	logrotate
Daily + up to 12 h	man-db.timer	man-db
Sunday 03:10	e2scrub_all.timer	e2fsprogs
Monday 00:00 + up to 100 min	fstrim.timer: discards unused blocks on SSDs	util-linux
15 min after boot, then every 24 h	systemd-tmpfiles-clean.timer	systemd

Some of these can land inside the early-morning window: the timers with a random delay of 12 h (apt-daily, man-db), sendmail's queue run every 20 min, and systemd-tmpfiles-clean, which runs at about 05:15 every day after a 05:00 reboot. All of them are light.

The early-morning window

The jobs around 05:00-06:30 are ordered on purpose:

1. 05:00: the host reboots, but only when an upgrade from the day before needs it.
2. 05:47: Watchtower updates the containers, well after the reboot and before the 06:00 jobs. It is kept off :00 on purpose (see below).
3. 06:00: apt-daily-upgrade starts within the next hour, and Scrutiny's collector runs.
4. 06:25: cron.daily.

A Watchtower run without errors takes a few minutes, so it is done before 06:00 and the updated containers are back up before the morning.

Speedtest Tracker is not part of this order. Its 04:00 UTC test (see Time zones) runs at 06:00 in Europe/Berlin summer time and at 05:00 in winter time.

Time zones

• Watchtower and Scrutiny use tz from settings.yml, passed to each container as TZ.
• Speedtest Tracker ignores TZ: it reads its schedule in DISPLAY_TIMEZONE, which the role does not set, so its tests run at 00:00, 04:00, 08:00 … UTC.
• Navidrome and Cloudflare DDNS run on intervals, so no time zone applies.
• The host timers, cron, the tinymotd timer and the unattended-upgrades reboot use the host's system time zone. The playbook does not set it.

Keep the host time zone equal to tz (sudo timedatectl set-timezone Europe/Berlin, with your own tz), or Watchtower and Scrutiny drift away from the host jobs (the 05:00 reboot, the timers and cron) by the offset.

Adding or changing a schedule

• Keep jobs that pull images from ghcr.io off minute :00. In Oct. 2026, ghcr.io answered image pulls with HTTP 429 (toomanyrequests) for about the first two minutes of every hour (see nicholas-fedor/watchtower#2730).
• Leave a margin after 05:00: the host may be rebooting.
• Finish heavy jobs before 06:00, when apt-daily-upgrade starts.
• Update this page in the same change as the role.