Slick landing page design, well done and congrats on your hard work.<p>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.<p>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:<p>1. Allow scheduling support for seconds. Obviously you'd have to get creative on this one.<p>2. Allow conditionals with rules-based triggers that are easily configured in a UI<p>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: <a href="https://laravel.com/docs/7.x/scheduling" rel="nofollow">https://laravel.com/docs/7.x/scheduling</a> - ultimately for #1 you'd want to take inspiration from <a href="https://stackoverflow.com/questions/9619362/running-a-cron-every-30-seconds" rel="nofollow">https://stackoverflow.com/questions/9619362/running-a-cron-e...</a><p>Good luck, have fun :-)
You realized that there are already free alternatives like <a href="https://cron-job.org/en/" rel="nofollow">https://cron-job.org/en/</a> on the market?!<p>I - personally - would never pay for a cron job service ...
Unfortunately, it's still missing the main cron-killer feature: randomized intervals.<p>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.
The landing page looks good. The UI screenshots are a little small and hard to read on my screen, but overall, the design is great.<p>You might also want to consider explicitly stating the value proposition: how will I save money/time/etc by using your service?<p>One possible use case that you might be missing are recurrent tasks that I want to <i></i>ensure<i></i> are run. For example, for my service, <a href="https://pagecheck.app" rel="nofollow">https://pagecheck.app</a>, 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: <a href="https://github.com/meyer9/postqueue" rel="nofollow">https://github.com/meyer9/postqueue</a><p>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.
What are the differentiators from a service like <a href="https://cloud.google.com/scheduler" rel="nofollow">https://cloud.google.com/scheduler</a> ?
> It's built for developers who don't like managing servers and working with cron jobs.<p>I had a hard time understanding the target market. Are they referring to frontend developers who are forced to do backend work?
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?<p>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).<p>But the explanation <i>given</i> was "oh we need this function (which is just a container running somewhere really) to "remain hot" so it responds quicker...<p>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.<p>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".
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.<p>That said, I think you will be competing in an up-hill battle with competitors.<p>- 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.<p>- Random polling: As other commenters mentioned, a loose scheduler can help those who want just want to casually spot-check stuff.<p>- 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.<p>- 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.<p>Good luck on your ventures!
Nice landing page man! :)<p>I have one question: What tool did you use to create the docs? => <a href="https://docs.cronhub.io/how-to-ping.html#ping-api" rel="nofollow">https://docs.cronhub.io/how-to-ping.html#ping-api</a>
Congrats on the launch and moving away from the free tiers for monitoring!<p>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!
Very cool. I wish it existed earlier when I was looking for solutions.<p>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.<p>[0] <a href="https://github.com/cronyo/cronyo" rel="nofollow">https://github.com/cronyo/cronyo</a>
Congrats, this looks awesome!<p>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?<p>Did you establish an LLC? Did you consult an attorney?
Cool landing page! Interestingly, I don't see any type of navigation menu (such as a hamburger menu) in the mobile page. Any particular design reason why you opted for that?