rpeat: A Better Way to Schedule Jobs

A cron alternative for a more civilized age

If you've ever tried to schedule a script to run on your computer you've probably used cron. And if you've used cron, you've probably also encountered the sinking feeling of realizing your job didn't run last night and you have no idea why. You might try SSHing into the server, digging through some logs (if they even exist), and eventually piece together what happened. Maybe you were missing an environment variable or maybe you tried to schedule it for 3am your time but the server is actually in a different time zone where 3am hasn't happened yet. It's a tale as old as, well, time (January 1, 1970 because that's when time started).

Cron is one of those tools that does exactly what it says it will do and nothing more. It runs your command at the time you specified. That's it. No alerts, no dashboard, no job dependencies, no history to look back on. If something goes wrong, you're on your own.

The Case Against (and For) Cron

To be fair to cron, it's been around since the 1970s and it's incredibly reliable for what it is. It's simple, it's everywhere, and it doesn't require any setup beyond editing a crontab file. If you need to run a backup script once a day on a single machine and you don't particularly care about monitoring it, cron is perfectly fine.

But here's where it falls short:

• No visibility: There's no built-in way to see if your jobs ran, how long they took, or whether they succeeded.

• No timezone handling: Cron runs on system time. You can't coordinate jobs across time zones or deal with daylight savings.

• No job dependencies: If job B needs to run after job A finishes, you're stuck chaining bash scripts together or adding arbitrary delays and hoping for the best.

• No team coordination: Crontabs are per-user and per-machine.

We used to just accept these limitations, but those limitations (among others) are why our friend Jeff Ryan wrote rpeat.

What rpeat Brings to the Table

rpeat is a job scheduler that feels like it was designed by someone who actually uses scheduled jobs regularly, because it was. It's a single binary you download and run with no complex installation process and is configured from JSON files that are easy to read and write.

The feature that sold us initially was the dashboard. Instead of SSHing into a server and grepping through log files, you can just open up the web interface and see exactly what ran, when it ran, how long it took, whether it succeeded or failed, and, most importantly, all the logs associated with a given run. It sounds simple, but it's genuinely life-changing when you're trying to debug whatever's going wrong with your jobs, or just want to keep an eye on everything.

rpeat also handles job dependencies, so you can say "run job B after job A completes successfully" rather than hoping the timing works out. It also has logic available to control whether child tasks run if their parent doesn't behave as expected. And if you're working on a team, there's granular permission controls so multiple people can manage and monitor jobs without stepping on each other's toes.

Because I'm a little bit of a nerd, I've also switched my personal projects over to rpeat. Two of the most important features for me are the job templating so I don't have to set the same options every time for every job (saving me like two whole seconds every time I add a job) and timezone support. Some of my scripts depend on the outside world and I want to make sure they're appropriately synced up and take daylight savings into account.

When to Stick with Cron

All that said, cron isn't going anywhere. If you're running a single script on a personal server and you don't need monitoring or alerts, cron is still the simplest option. It's already installed, it requires zero setup, and it just works. I wouldn't tell someone to set up rpeat just to run a log rotation script once a week.

The tradeoffs look something like this:

Feature	cron	rpeat
Setup complexity	None (pre-installed)	Low (single binary download)
Dashboard	No	Yes
Timezone support	System time only	Configurable per job
Job dependencies	Manual workarounds	Built-in
Alerting	Manual configuration	Built-in (email, Slack, webhooks)
Team features	None	Permissions, multiple users
Cost	Free	Server free, hosted alerts start at $12/mo

Getting Started

If you want to try rpeat, the rpeat website has all the documentation you need, but we recommend setting up the demo project. The demo will create all the files you need for you so you don't have to do it yourself. The server itself is free, so there's nothing stopping you from downloading it and playing around. The setup is straightforward: download the binary for your platform, create files defining your config, auth, and jobs, and start the server. The dashboard runs locally by default, though you can configure TLS if you need to access it remotely.

I've been using rpeat for my personal projects for a while now, mostly because I got tired of checking whether my scripts actually ran and I wanted a convenient way to view the logs for each run. Having a dashboard where I can see everything at a glance, combined with the ability to set proper timezones, has made my life noticeably easier. We've also been using it here at Lander Analytics. It's a good tool and we're grateful to Jeff for making it.

Wrapping Up

Cron has its place, and I'm not suggesting anyone rip it out of their systems tomorrow. But if you've ever lost sleep wondering whether your overnight job ran, or spent an afternoon untangling timezone issues, rpeat is worth a look. It's one of those tools that solves problems you might not have realized were solvable.

Gus Lipkin

Data Scientist

Lander Analytics

---

Subscribe to our Substack and below to our monthly emails for practical AI strategies for your organization: what to build, what to avoid, and how to make systems reliable in the real world.

Work with us: If you want help identifying the right first workflow, building a permissioned knowledge base, or training your team to ship responsibly, reach out at info@landeranalytics.com.

About the author: Gus Lipkin is a Data Scientist at Lander Analytics, where he writes software for data science practitioners and consumers.