Crontab handling

rippler sync edits your crontab. Here is precisely what it does, because a tool that rewrites your scheduled jobs should not be mysterious.

What it changes

For each job with no monitor, it creates one and wraps the line:

- 0 3 * * * /usr/local/bin/backup.sh --full
+ 0 3 * * * rippler exec 0kDRYQz -- /usr/local/bin/backup.sh --full

The schedule is untouched, and so is the command. Indentation is preserved.

What it leaves alone

• Comments and blank lines.
• Variable assignments like MAILTO= or PATH=.
• Lines already wrapped, whose monitor still exists. Running sync twice is a no-op, which is what makes it safe in a provisioning script.
• @reboot, which has no schedule to expect pings against. It is reported and skipped rather than given an invented one.

Schedules it understands

Standard five-field expressions pass through as they are. The shorthands are expanded, since the API needs a real expression:

Naming

Monitors are named after the program the job runs — /usr/local/bin/backup.sh --full becomes backup.sh. Rename them in the app; sync will not rename them back, because it matches on the monitor id in the wrapper, not on the name.

If something goes wrong

Before installing anything, sync writes your current crontab to ~/.rippler/crontab-backup-<timestamp>.txt and prints the path. To undo:

crontab ~/.rippler/crontab-backup-2026-08-29T03-08-11-803Z.txt

Monitors that were created are not removed by restoring the crontab — delete them in the app if you do not want them.

A monitor that no longer exists

If a line points at a monitor that has been deleted, sync reports it and moves on:

! line 6 points at monitor jGDc_zz, which is not in this account

It will not silently create a replacement, because that would leave you with a duplicate every time someone tidied up in the app. Remove the wrapper from that line and run sync again to have it recreated.