Show HN: I built a cron job scheduler
blog.cronhub.io
blog.cronhub.io
As others have said the market is saturated and engineers would implement this themselves. Don't let that deter you, though, there's still room for innovation.
If you can get user feedback I'm sure you can find a niche or killer feature that makes your product worth paying for. For me, I have two things I'd like to see in a paid service:
1. Allow scheduling support for seconds. Obviously you'd have to get creative on this one.
2. Allow conditionals with rules-based triggers that are easily configured in a UI
Those would require you create something more akin to Laravel's Console setup instead of working directly with Cron directives, but that's something worth considering! In that setup, a Cron is pointed at the Laravel configuration and it runs every minute: https://laravel.com/docs/7.x/scheduling - ultimately for #1 you'd want to take inspiration from https://stackoverflow.com/questions/9619362/running-a-cron-e...
Good luck, have fun :-)
I - personally - would never pay for a cron job service ...
And if you don't wanna write crontab syntax, then there are other free alternatives like IFTTT
https://help.github.com/en/actions/reference/workflow-syntax...
What makes cron-job.org not an alternative for us, is that this they monitor by crawling a URL that you provide. This is limiting and doesn't serve our use case for backend system monitoring.
By contrast, Cronhub gives us a public endpoint that we must ping by a certain interval to say that our service ran in the interval.
We also use their slack integration to show any monitoring failures in our #fires channel!
It's a monitoring service that "just works" and we don't have to maintain it, and if things go wrong we can reach out to someone since we are paying customers.
Also Tigran is very responsive!
That's why Linux doesn't have more users than Windows.
Do you realize that price isn't the only thing!?
I have 200 servers that I need to run some task every 3 hours. But I don't want them to all run at the same time. I need options to either "start this task at some point randomly in the next 3 hours, then every 3 hours thereafter" or "run this task randomly in every 3 hour block", without resorting to manually tweaking hour/minute run times on every server.
Find a value that is unique to each server (e.g. the UUID of the / partition?) to seed your PRNG, and then generate the first pseudo-random number. If you do it right, it will always be the same number.
Modulo this number against the number of (seconds|minutes|hours) of random delay you want applied, and apply a sleep timer to the start of the job based on that result.
It's dirty, but it ensures
* each server gets its own random interval from the start time
* that random interval never changes
* the server runs the job on a regular schedule
There are probably better ways of doing this, but this is the first thing I could think of that doesn't require any crazy libraries and can be done using standard linux utils that are on all machines.
I'd love to hear any better ways that people have!
FWIW, that's pretty much what /etc/machine-id is for.
It has the every N since last run option.
A few ideas off the top of my head: write a unit template and use the instance parameter to designate an offset; or write a single unit template with the `OnCalendar` property set to `*:00:00/3:00:00` and `RandomizedDelaySec` set to (10800) (3 hours in seconds).
Of course, the same basic effect is also possible with traditional cron. Certbot's Debian package has a pretty basic example of how to do basically what you want: have the job set to run every 3 hours, and then have the command be something akin to: `perl -e 'sleep int(rand(10800))' && <your command>` - it's the exact same high level logic as the systemd approach, but you're inserting the delay yourself using a `sleep` call.
I'd personally very much go for the systemd approach but either should work.
For example, to run a task at some point between midnight and 3 a.m., you can use this cronjob entry:
0 0 * * * sleep $(( $$ \% 10800 )) && /foo/task.sh
(Note: 10800 == 60 x 60 x 3, the number of seconds in three hours.)
You might also want to consider explicitly stating the value proposition: how will I save money/time/etc by using your service?
One possible use case that you might be missing are recurrent tasks that I want to ensure are run. For example, for my service, https://pagecheck.app, I run tests every 30 minutes or so and I want to make sure those tests succeed. I couldn't find a job scheduler that allows for recurrent tasks, so I ended up writing my own Javascript library for Postgres: https://github.com/meyer9/postqueue
I'd love an external service that ensured that my recurring tasks run reliably, but it would make 0 sense for me to use your service at that price level. I have hundreds or thousands of scheduled tasks, but I can't pay thousands of dollars to ensure that they are run.
Great stuff!
I use Google Cloud Scheduler a lot (manage dozens of cron configs) so have some thoughts on how they compare:
For monitoring, I definitely like what CronHub supports. I wish Cloud Scheduler had a similar monitoring API. As such, I have to do all that myself. The logs for Cloud Scheduler attempts are not connected to the logs of the jobs that get kicked off.
On ease-of-use, I'd say CronHub and Cloud Scheduler look about equal. Both have a Web UI, an API, and a CLI. However, Cloud Scheduler is supported by Google's Terraform plugin, which allows me to manage dozens of scheduler configs as Infrastructure-as-Code across several environments with ease. Obviously Cloud Scheduler also supports additional things like granular permissions (Cloud IAM) for different config management operations and authentication for scheduler requests, which are key to managing lots of configs for several teams and running secure infrastructure.
Feedback (some of this may already be on your roadmap):
- I'd recommend you create a Terraform plugin or at least provide some examples for the various IaC tools out there.
- Another differentiator you could add would be a cron schedule visualizer (for the cron-expression-impaired like myself) that shows all of one's cron configs and how they line up. That would help with situations where you're trying to arrange your crons to not compete with each other, or when you want to make sure the crons kick off in a certain order with gaps in between.
- Parts of cronhub.io drop into sub-domains, it'd be nice if there was a persistent navigation across them all so I don't have to just click the back button to figure out how to get out of e.g. crontab.cronhub.io when I want to get back over to the documentation.
- You should add at least some simple security to both the cron webhooks and the ping API. My app would like to verify that the cron request is definitely coming from CronHub. And CronHub should definitely want to verify that incoming ping requests from my crons are coming from my app. Similar to https://developer.github.com/webhooks/securing/.
- Not sure about pricing structure. Who only has 1 or 5 cron jobs? Even as a solo dev with some side projects I'd have to get a custom plan. I'd say be generous with Schedulers and charge for your differentiators (for $49/month I can get ~500 crons with Cloud Scheduler, but no good/easy monitoring of those jobs).
- Perhaps rename "Custom Plan" to something like "Enterprise Plan" or the "Scale up" plan or something. The larger businesses that will sustain you want to feel special when they look at your pricing plan.
- You'll want to offer Log Export (Enterprise plan?).
- It's not clear to me what the team collaboration aspect of your product is. Why wouldn't I just have a single user and manage/monitor everything through your API/CLI and Slack/Webhook integrations?
- One other piece of feedback: The text-shadow on your homepage is too much for me (I'm on Chrome on a Macbook), it's hard to focus on the text, I even checked my glasses for fog/smears when I landed there.
That said, I find your product inspiring (especially the no-free tier)! You present it in a personal way that makes it feel legit and loved, quite different than the dime-a-dozen SaaS landing pages that fly through here. Good luck!
Some of the things you mentioned is on my roadmap but some are new to me. I love the idea of cron visualization.
For pricing, I agree, my current setup is not ideal and I plan to iterate on it in the next couple of months.
I had a hard time understanding the target market. Are they referring to frontend developers who are forced to do backend work?
Increasingly, people in one area are expected to take on the responsibilities of other areas. This invariably ends up in disaster the moment you've scaled past the point that inexperienced person can go. Not because that person doesn't have good intentions, or ability to read manuals, but because some things you only learn by doing the hard way.
DevOps tries to turn developers into sysadmins. Sysadmins make fantastic scripts to manage their servers. Developers make fantastic programs. The skills are similar but ultimately very different, the problem domains are very different, and the thought processes required are very different.
"Oh I can just copypasta this from stackoverflow" is a terrible way to develop or administer systems. The danger is squared when it's the area you care less about, as you have even less chance of detecting when you're doing it wrong.
Alas, business needs don't allow for the right thing to be done from the start, which is reasonable as the money needs to go on generating more money and fast.
Which is why every business has technical debt, always and forever, and overpaid consultants will always have jobs pointing out where the problems are for other people to fix.
That said, most deployment platforms have their own task scheduler systems. And https://cron-job.org/en/ does this for free. So, I understand the market but I don’t understand why anyone would pay for this.
But cheers & best of luck to the maker!
In all the time I've seen this type of thing posted, I've seen one explanation that had the potential to make sense: an app that runs via "Functions As A Service" (if you call it 'server less', I will hit you, with the server it's running on).
But the explanation given was "oh we need this function (which is just a container running somewhere really) to "remain hot" so it responds quicker...
So it's not that they needed to run some job every $n minutes, that was a kludge work around. What they needed was either a FAAS platform that allows for minimal worker scaling (you know, like forking/threaded web servers have done for decades); or, and hold onto your hats here, I know it's a crazy idea: they needed a server that's always on.
I know that the author probably put a heap of effort into this tool, just as all the other "cron as a service" authors did - but I'm sorry, I just don't get it. At this rate, I will not be surprised when an un-ironic "printf as a service" is posted to "Show HN".
That said, I think you will be competing in an up-hill battle with competitors.
- CI/CD systems: This is how I would personally setup my jobs. I can go as far as SSH-ing to a remote server, and execute a script there, assert a certain output in the stdout, and mark build as failed. CI/CD system can then alert whoever is responsible. I don't think extremely technical developers are your target audience. The right balance would be a UI that can make this easy.
- Random polling: As other commenters mentioned, a loose scheduler can help those who want just want to casually spot-check stuff.
- Granular schedules: One might need to run an indexer every 10 minutes Mon-Fri 08:00-17:00, and hourly in weekends. Instead of using two schedulers, it might be both financially and cognitively easier to have just one scheduler.
- Add features to expect a certain output to mark the job as passed. This can be an HTTP status code, a certain regular expression, a time-out threshold, etc.
Good luck on your ventures!
I have one question: What tool did you use to create the docs? => https://docs.cronhub.io/how-to-ping.html#ping-api
That can be a scary step but if you want to get paid so that you can afford to keep working on cronhub then it makes sense!
Shameless plug: Ended up creating an open source CLI for AWS cloudwatch[0] that works pretty well for us, but it’s less slick obviously.
How do you deal with getting money (I can see stripe), tax implications and potential liability? Did you consult tax or any other attorneys? Who drafted your terms of service?
Did you establish an LLC? Did you consult an attorney?
We use Visual Cron for ETLs, that would tell me that there's a market..?