Everything else in these docs is a command you type. This is the one that runs when you are not there — and it is not a wrapper around your scheduler. sloop registers itself with the machine's own service manager and does the work itself.

Showing Linux. What gets registered, and how you elevate, both change with it.

Nothing is written to crontab or a systemd timer. The service takes the backup itself and applies the retention policy itself — running the same backup and backups prune you would have typed, with --yes and never --force.

Elevation, before anything happens

On Linux sloop registers a systemd unit at /etc/systemd/system/sloop.service. Changing what a machine runs at boot needs an administrator, and sloop checks that before it does anything rather than failing halfway with a permission error:

not elevated

$ sloop service installerror: changing what this machine runs at boot needs more than this account has, and  systemd will refuse  hint: run it again with sudo. Nothing has been changed by this run.

Nothing has been changed by this run. That is the part worth trusting — the check happens first, so a refused run leaves the machine exactly as it was. To go ahead, run it with sudo and run sudo sloop service install.

Four service commands need that, and five do not — and so do reset and uninstall, which take the service off the machine as part of removing everything else sloop put here:

Command	What it does	Needs elevation
`service install`	registers it with the machine	yes
`service uninstall`	takes it off again	yes
`service start`	starts it now	yes
`service stop`	stops it now	yes
`service attach`	watch a database	no
`service detach`	stop watching one	no
`service schedule`	back one up on a schedule	no
`service status`	installed, running, last run, next run	no
`service activity`	what it has recorded	no
`reset`	puts the machine back to a fresh install	yes, when a service is registered
`uninstall`	the same, plus the binary	yes, when a service is registered

install takes --no-start to register it and leave it stopped, --interval <SECONDS> for the gap between rounds of readings (60 by default), and --user <USER> to run as a particular account — Linux and macOS only, because a Windows service runs as LocalSystem.

Attaching a database

Installing the service does not make it watch anything. service attach does, and it is picked up without a restart:

one database

$ sloop service attach ordersAttached. the service watches orders from its next round  no sloop service is installed here — `sloop service install` registers one and starts it

The service only watches the global registry

A service has no working directory, so there is no project for it to be standing in. A database registered only in a project cannot be attached, and this is the first thing that goes wrong for somebody who put everything in one.

exit 2

$ sloop service attach orders   # registered in a projecterror: there is no database called orders in the global registry  hint: the service has no working directory, so it can only watch the global store.  `sloop db list --global` shows what is in it, and `sloop db add --global` puts  something there.

sloop db add <name> --global … is the fix, and which registry a bare name means is the page for why there are two.

and back off again

$ sloop service detach reportsDetached. the service stops watching reports at its next round  nothing had been recorded about it yet

Detaching stops the watching. It does not delete anything already recorded — and neither does service uninstall.

Scheduling a backup

Attached means sampled. Scheduled means backed up, and that is a second, separate step:

nightly, with retention

$ sloop service schedule orders --every 1d --keep 7 --keep-for-days 30Scheduled. orders is backed up every day  the newest 7 are kept, and anything older than 30 days is pruned  no cron line, no scheduled task — the service takes it  no sloop service is installed here — `sloop service install` registers one and starts it

One line, and it carries both halves: --every 1d is how often, and --keep 7 --keep-for-days 30 is what survives. The retention is applied by the service after each run — and only after a backup that worked, so a failed night never prunes the copies that succeeded.

--every takes 30m, 6h, 1d, 2w — the same spelling backups prune --older-than takes.

off, and on again

$ sloop service schedule orders --offStopped. orders is still attached and still sampled — nothing backs it up now $ sloop service schedule orders --every 6h --keep 10Scheduled. orders is backed up every 6 hours  the newest 10 are kept, the rest are pruned

--off stops the backups and leaves the database attached, so it keeps being sampled for activity. Attaching and scheduling are separate on purpose, and turning one off does not turn the other off.

A missed run, and a collision

A machine that was asleep for a week does not wake up owing you a hundred and sixty-eight backups. A missed run is caught up once and labelled late, and the next one is measured from now rather than from the schedule it fell off.

And if a scheduled run meets one you started by hand, the schedule stands aside: one lockfile per database, and the run that finds it held exits 7 having taken nothing. The manual run finishes untouched.

Checking on it

service status answers four questions: installed, running, last run, next run.

before anything is set up

$ sloop service statusService  State not installed  Managed by systemd  `sloop service install` registers it with this machine Watching nothing — `sloop service attach <name>` attaches a database

two attached, one scheduled

$ sloop service statusService  State not installed  Managed by systemd Watching 2 databases  orders  attached 2026-09-19 20:59:58 +06:00 · not picked up yet · no activity recorded      backed up every day · never run · next 2026-09-19 20:59:59 +06:00  reports  attached 2026-09-19 20:59:58 +06:00 · not picked up yet · no activity recorded      no backup schedule — `sloop service schedule <name> --every 1d`  no service has ever read this list

Every line of that is a fact rather than a guess — not picked up yet, never run, no service has ever read this list. On a machine where the service is installed and running, those become the times it actually ran and the time it runs next.

and what it has recorded

$ sloop service activityActivity 2 databases attached orders  nothing recorded yet — attached 2026-09-19 20:59:58 +06:00  no running service has picked it up yet reports  nothing recorded yet — attached 2026-09-19 20:59:58 +06:00  no running service has picked it up yet   rows are what the server counted; Moved is real bytes sloop read or wrote. Nothing  here is bytes on the wire — no engine reports those per database.

Activity and monitoring is the page for what those numbers are and, just as importantly, what sloop will not pretend to measure.

From nothing to a nightly backup

Four commands, and only the first needs an elevated terminal:

sudo sloop service install — register it with the machine.
sloop db add orders --global --url … — the service reads the global registry.
sloop service attach orders — start watching it.
sloop service schedule orders --every 1d --keep 7 --keep-for-days 30 — nightly, keeping a week, pruning after a month.

Then sloop service status whenever you want to know it is still true. Every flag any of these takes is on the command reference.