Show HN: I built a cron job scheduler

Congratulations on the launch. I like the landing page and the justification for the lack of a free tier. Cronjobs are often set-and-forget tasks that a free tier can attract a lot of free users that are hard to turn into paying customer. A well-defined pricing structure with well-defined features can bring customers who settle-in for the long term.

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!

Disclaimer: I work in Google Cloud, my opinions are my own.

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!

I am still struggling to see how such a basic service is actually used? Is it just because it's (presumably?) a GUI to create the job(s), and a portion of people deploying services today are just not comfortable writing a cron entry, or a systemd timer unit?

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".

Wow, thank you so much for the great feedback. I appreciate it.

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.

Tests in my case mean page checks I run for my customers. Not tests on my code.