Running your cron jobs — and being honest when we can't

For a while now, CaneCron has watched cron jobs: your script pings us when it finishes, and if the ping doesn't arrive on time, you get an alert. It works well. But the question people kept asking was the obvious next one — can you just run the job for me?

So now we can. You give CaneCron a URL and a schedule, and we call it on time, every time. Same object watches the result. If it fails, you hear about it. That's the feature in one sentence.

The interesting part isn't the running. It's what happens when we fail.

The question nobody likes to answer

If a service runs your jobs, there's an uncomfortable question hiding in it: what happens when that service goes down? Your job was supposed to run at 03:00. The service was offline at 03:00. Now what?

Most tools handle this in one of two ways, and both are bad. Some silently drop the run — no record, no signal, as if it never should have happened. You find out weeks later, the hard way, like a backup that quietly stopped. Others do something worse: they send you a "your job failed" alert. But your job didn't fail. They failed. That alert is a lie, and it arrives at the exact moment trust matters most.

We didn't want to do either.

Three outcomes, one of them honest

Every run in CaneCron ends in one of three states:

• Success — your endpoint answered, all good.
• Failed — your endpoint errored, timed out, or didn't respond. This one's on you, and we'll tell you.
• Missed — we couldn't run it. This one's on us.

That third state is the whole point. A missed run is never counted against you, never triggers a failure alert, and is never dressed up as your problem. When we recover from an outage, CaneCron works backwards: it reconstructs exactly which runs it dropped while it was down, records each of them truthfully, and links them to the outage that caused them. Your history shows the truth — "we were down, these didn't run, that was us" — instead of a wall of false failures.

Building that honestly was more work than building the runner itself. It's easy to record what happens while you're up. Recording what you failed to do while you were down means a system that can't trust its own logs for the window it wasn't running — so we lean on an independent watcher to know, for certain, when we were offline, and reconcile against that.

Why bother

Because monitoring is a trust business. The entire value of a tool like this is that you can stop thinking about the thing it watches. A monitoring product that lies about its own failures — even small, convenient lies — isn't worth trusting with the things that matter.

So we built the version that tells the truth, including the truths that make us look bad. If we drop your job, you'll know it was us. That seems like the least you should expect from something you're trusting to run your work.

Scheduled Jobs is live now. Every call is signed so your endpoint can verify it's really us, jobs run in the timezone you choose, and you can pause, edit, and see full run history for each one. If you've been pinging us to say "I finished," you can now let us handle the running too.