Nobody gets paged when a cron job runs fine. You only find out something's wrong when a customer emails asking where their invoice is, or someone on support notices a dashboard hasn't updated since Tuesday. By then the job's been failing or half-failing, which is worse because it can look like success until you check the actual numbers for who knows how long. And if you go check the log, it usually just says the script started. Nothing about why it stopped, or where.
That's really the whole reason teams end up moving off cron, Windows Scheduler, or Kubernetes CronJobs. It's not that scheduling is hard that problem's been solved for thirty years. It's that somewhere along the way, "run this at 2am" turned into a chain of five API calls, three of which can fail on their own, and nobody ever sat down and decided what should happen when step three times out.
At that point you're not maintaining a schedule anymore. You're maintaining a small distributed system. Most teams don't clock that this happened until an incident forces them to look closely.
The build-your-own trap
The instinct is to patch the cron job. Add a retry loop. Write failures to a table. Wire up a Slack webhook for alerts. Each change makes sense in isolation, and a few months later you've built something that behaves like a workflow engine without ever being designed as one.
That matters because none of those early decisions get revisited. Retry logic written for one script gets copy-pasted into five others with completely different failure semantics. Nobody versions the workflow definition, so a change to "how we send the welcome email" quietly changes behavior for every script that imported that function. Debugging turns into: SSH into a box, grep a log file, go ask whoever wrote it eighteen months ago.
This isn't a hypothetical it's the natural end state of pushing a scheduler past what it was built for. The first version of an in-house engine is rarely the expensive part. Keeping it correct across teams, failures, and changing requirements for years is.
A rough test for whether you've outgrown cron
Ask three questions about the job:
If step 2 of 4 fails, does only step 2 retry, or does the whole thing rerun from the top?
Can someone outside the team that wrote it see what happened last Tuesday, without reading source code or SSHing anywhere?
If the input needs to change per-run (a webhook payload, a form submission, an API trigger), does the current setup support that without editing the script?
If the answer to any of these is "not really," you've already left scheduling territory and moved into orchestration whether or not you've called it that.
Where a platform like Unmeshed fits
This is the specific gap orchestration platforms close: structured retries per step, execution history that doesn't require log-diving, and workflows that can be triggered by schedule, webhook, API, or a form, using the same definition. It doesn't replace cron for a log-rotation script nobody needs visibility into. It replaces the internal engine you'd otherwise end up building and then owning once a job stops being a single script and starts being a process other teams depend on.
Top comments (0)