Show HN: I built a cron job scheduler

(blog.cronhub.io)

84 points | by thakobyan 1400 days ago

16 comments

  • zschuessler 1399 days ago
    Slick landing page design, well done and congrats on your hard work.

    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 :-)

    • jiux 1399 days ago
      Your approach on providing feedback is clean, to the point, and most importantly, encouraging. Well done, Zachary.
    • thakobyan 1399 days ago
      Thank you! :)
  • Wronnay 1399 days ago
    You realized that there are already free alternatives like https://cron-job.org/en/ on the market?!

    I - personally - would never pay for a cron job service ...

    • mikece 1399 days ago
      In many cases, paying for a service you could do yourself is more about having a throat to choke in case something goes wrong. I'm sure I could figure out cron/crontab if I took the time to learn about it but that's not my core skillset so paying $5/month is actually rather cheap for me (especially when the cost is passed along to a client who is less skilled at these things than I am).
      • Wronnay 1399 days ago
        Cron-job.org uses a similar interface and is much older than this project.

        And if you don't wanna write crontab syntax, then there are other free alternatives like IFTTT

      • pkaye 1399 days ago
        And what happens when this service you depend on gets shut down for whatever reason?
        • mikece 1399 days ago
          I get to bill the client for moving them to another service.
          • quickthrower2 1399 days ago
            So best to choose one that's gonna shut down soon :-).
    • rchasman 1399 days ago
      My startup is a Cronhub customer.

      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!

    • tyingq 1399 days ago
      On the other hand, I'm not sure I'd upload credentials into a free-as-beer site. I assume there are self hosted, open source, cron web ui projects.
    • josephd79 1399 days ago
      Personally, you get what you pay for, also If I use something a lot I do not mind paying a few bucks a month to someone that worked hard creating it.
    • politelemon 1399 days ago
      I was also thinking, it's a bit lower level but, using Github Actions with the 'on.schedule'

      https://help.github.com/en/actions/reference/workflow-syntax...

    • johnwheeler 1399 days ago
      I’m sure plenty of people thought the same thing about statuspage, yet they seem to be doing fine. People like easy and centralized. I think it’s a great idea, and there’s room for value-adds later down the line.
    • nkkollaw 1399 days ago
      There are many reasons why people will pick up a paid product over free.

      That's why Linux doesn't have more users than Windows.

      Do you realize that price isn't the only thing!?

    • Axsuul 1399 days ago
      Cron is such an important piece of your infrastructure. Are you sure you want to depend on a free service for this?
      • caogecym 1399 days ago
        People can select multiple cron vendors for critical flows, this helps make sure we could notice when one vendor doesn’t silently goes down.
  • parliament32 1399 days ago
    Unfortunately, it's still missing the main cron-killer feature: randomized intervals.

    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.

    • oarsinsync 1399 days ago
      As a workaround, sounds like you need a deterministic pseudo-random number generator.

      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!

      • jlgaddis 1399 days ago
        > Find a value that is unique to each server (e.g. the UUID of the / partition?) ...

        FWIW, that's pretty much what /etc/machine-id is for.

    • stephenr 1399 days ago
      I'd imagine that systemd timers would work here, and I would imagine would be less work than having to have 200 jobs in some 3rd party service.

      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.

    • jlgaddis 1399 days ago
      In my experiences, the "standard" way to do this is to simply add a random sleep before running the task.

      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
      
      Alternatively, systemd has the "RandomizedDelaySec" option.

      (Note: 10800 == 60 x 60 x 3, the number of seconds in three hours.)

    • openthc 1399 days ago
      You may want to checkout fcron

      http://fcron.free.fr

      It has the every N since last run option.

      • edoceo 1399 days ago
        And jitter and random features too
  • jmeyer2k 1399 days ago
    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.

    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.

    • Ayesh 1399 days ago
      Pretty much every CI/CD system supports scheduled builds. GitLab CI, GitHub Actions, Travis, Circle CI, and even Jenkins do.
      • jmeyer2k 1398 days ago
        Tests in my case mean page checks I run for my customers. Not tests on my code.
  • sna1l 1399 days ago
    What are the differentiators from a service like https://cloud.google.com/scheduler ?
    • thakobyan 1399 days ago
      For now, the only difference is the ease of use and monitoring.
      • pseudobry 1399 days ago
        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!

        • thakobyan 1399 days ago
          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.

  • zachguo 1399 days ago
    > It's built for developers who don't like managing servers and working with cron jobs.

    I had a hard time understanding the target market. Are they referring to frontend developers who are forced to do backend work?

    • oarsinsync 1399 days ago
      Programmers are not sysadmins are not network engineers are not tech support are not DBAs are not ...

      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.

    • pnwhyc 1399 days ago
      Many web backends are deployed to platform-managed runtime-specific container environments. The idle Linux monolith is becoming less common. In these environments, it’s often easier to set up a cron webhook endpoint than to write a DIY task scheduler.

      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!

  • stephenr 1399 days ago
    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".

  • Ayesh 1399 days ago
    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!

  • moritzmoritz21 1399 days ago
    Nice landing page man! :)

    I have one question: What tool did you use to create the docs? => https://docs.cronhub.io/how-to-ping.html#ping-api

  • harrisonjackson 1399 days ago
    Congrats on the launch and moving away from the free tiers for monitoring!

    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!

    • thakobyan 1399 days ago
      Thanks for the support! Yeah, this was a hard decision but hopping the right one for future sustainability.
  • Arimbr 1400 days ago
    Nice, I also think that backend engineering needs more innovation!
  • gingerlime 1397 days ago
    Very cool. I wish it existed earlier when I was looking for solutions.

    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.

    [0] https://github.com/cronyo/cronyo

  • dhdhhdd 1399 days ago
    Congrats, this looks awesome!

    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?

  • su8898 1399 days ago
    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?
  • nkkollaw 1399 days ago
    Looks great!

    We use Visual Cron for ETLs, that would tell me that there's a market..?

  • dandanio 1399 days ago
    I am sorry, but I can't stop thinking how useless this service is.
    • hamstu 1399 days ago
      Sorry, but I can't stop thinking about how useless your comment is.