What you see
For each schedule:
By default, a schedule has no timezone set, meaning “2 AM” is 2 AM on your server’s own system clock — which may not match your own timezone if the server runs on UTC or is hosted somewhere else. Pass
--timezone when creating the schedule (e.g. --timezone "Africa/Lagos") to pin it to a specific zone instead — see capsule schedule for the full explanation and more examples.
Managing schedules
Schedules are created and removed from the CLI on your server:Schedule execution
Schedules are executed by the Capsule daemon (capsule service) running on your server. The daemon must be active for scheduled backups to fire — if it isn’t running, nothing checks the clock, so nothing runs.
Check daemon status:
Missed backups
If the daemon is offline when a scheduled backup should have run, Capsule doesn’t just silently skip it — it catches up once, the moment the daemon comes back online. Example: say you have a daily backup scheduled for 2 AM, and your server is rebooted for maintenance from 1 AM to 5 AM. The 2 AM window passes while the daemon is down. As soon as the daemon starts again at 5 AM, it notices that the schedule’s next expected run time has already passed, and immediately runs one backup to catch up — it won’t wait until the following 2 AM. This catch-up backup appears in your history tagged ascatchup, distinct from a normal scheduled run, so you can tell the two apart.
This only catches up one missed window, not every window you missed. If your server was down for three days and you have a daily schedule, you get one catch-up backup on restart, not three — Capsule doesn’t try to reconstruct backups for days you were offline, since the underlying data has already moved on by the time it’s back.
To minimize how often this happens at all, install the daemon as a boot-time service so it restarts automatically after a reboot instead of staying down until someone notices: