Introducing Cronhub Scheduler and What’s Next

Two years ago, I launched Cronhub's first version. I started it as a Cron Monitoring tool and helped thousands of developers to monitor their cron jobs. Today, I'm excited to announce the launch of a new product that I call Scheduler and write a bit about my future goals.

Cronhub Scheduler is a job scheduler to automate workflows and run jobs on a recurring basis. I built Schedulers for developers who don't like working with servers and complicated cron jobs. Think of it as a friendlier alternative to traditional cron jobs.

I see Cronhub monitoring and scheduler as two products that complement each other. For every job you create, you should have monitoring in place so you can be aware of any failures.

Why Scheduler?

I've been working with infrastructure and backend services for a long time. In fact, as a full-stack engineer, I've always been more into the backend. Although there has been some recent innovation in the backend space, I still believe that for most developers backend engineering sucks.

Working with servers or containers is complicated and overwhelming. The Developer Experience (DX) is just not there yet. Instead of focusing our efforts on building amazing products, we get stuck on writing backend pipelines, scheduling cron jobs, monitoring services, and writing APIs to connect backend with our sites or mobile apps.

If we compare backend engineering with frontend, we see a big contrast. Frontend technologies are sprouting. Browsers are becoming more powerful, which means they can do more work for us. If we want to build sites now, we can package everything into a single static binary and run it on the browser. With a CDN in place, sites become so much faster. Faster that one could have imagined.  This trend is huge because it enables us to build products faster with better performance. Of course, not everything is ideal, but I believe that improved tooling and technologies accelerated the progress of frontend engineering.

Unfortunately, we can't tell the same for the backend. Most existing tools are low-level and require expertise in systems, databases, networking, containers, and more. This creates an entry barrier for many developers and makers who want to build things for the web that require some sort of backend infrastructure. It's just too much to learn. With the rise of serverless, this is gradually changing, but still, some workflows are inevitably complex.

There aren't many no-code and low-code tools that could improve the developer experience and tooling for backend engineering. I think we can innovate the space if we start building higher-level abstractions on top of existing low-level tools. If there were more, we could finally make building backend services more accessible and simpler.

Let's think of Kubernetes for a moment. I think in 5-10 years we'll talk about Kubernetes as much as we talk about Linux now. Most of us don't directly work with the OS (Operation System) level but rather work with higher-level tools that help us to manipulate the state of the system. So maybe in 5 years, Kubernetes becomes the next evolution of the OS that most people can neglect when writing backend software. Cloud innovation enables this, and we should take a full advantage of it.

Not to go astray, but this is where I found my true passion.  I love building high-level tools for developers that provide exceptional developer experience. I want those tools to be easy to use and accessible for most makers.

My goal with Cronhub is to make job scheduling and monitoring extremely simple. Traditionally, it's been done with complicated cron jobs, and I hope to change it for better.

How does Scheduler work?

With Cronhub Scheduler, you can focus on your application, and we handle the scheduling part. Let's say you want to send a daily email to your users. You can work on creating the function that handles the email sending part, and we take care of the whole scheduling logic behind the scenes. You just need to tell us where your function lives and how often you want to run it.

Or, if you want to create on-demand scheduled workflows, you can use our API to schedule things. It's that simple.

The schedule can be any cron expression (e.g. 0 0 * * *) or time interval (e.g. every 3 hours). I find working with simple time intervals a lot easier, but most people who need more complex schedules (e.g. every Wed on 5 pm EST) prefer cron expressions.

We started Scheduler with URL targets only but the goal to expand from here. The opportunities are endless. Imagine a workflow where you can pull-in your serverless functions within Cronhub and easily schedule them to run via a coherent UI. This is just one example, but I have many things that I want to work on.

Monitoring and Scheduling together

When you schedule a job, you want to know if it failed. You can use our monitoring solution for this, but, as of now, it requires some manual work in your function. You need to ping from your function to the  Cronhub monitor every time it runs. The good part of this manual integration that we can easily monitor your job running time, too, in addition to the uptime.

However, soon we will launch a built-in monitoring feature for schedulers. You can get alerts based on the status code of your function and get alerts with multiple notification channels like Email, Slack, or SMS. This makes the scheduling part even more seamless.

Only paid plans

I want to make Cronhub a sustainable business that I can eventually work on full-time. Apart from the obvious operational costs, Cronhub costs me much time, and I want to get paid for it. It still is my side-project, so I spend my weekends and evenings on building it. Building a product that other people find useful and pay for is incredibly fulfilling, and I want to keep it up.

From now on, I won't support any free plan. We have 3 affordable plans for all developers and teams - Starter ($5/m), Pro ($12/m), and Startup ($49/m). Of course, we also provide custom packages for users who need a plan designed for their needs. I've grandfathered all existing free users. They still can continue using Monitoring for free.

To be honest, I'm nervous about this change. During all my developer career, I've built many side-projects and gave it for free. I don't regret it, but I know it's not sustainable for me. Today, I'm changing this for Cronhub so that I can focus on it long-term. I'm excited to see how this goes.

What's next?

I have so much to do to improve the product. I have many ideas that I think are worth exploring. Soon, I plan to add built-in Monitoring for the schedulers based on the job's response status code and the ability to send headers with the request. I could have waited to finish these features before I launched but decided not to. I wanted to get this out and get some early feedback.

Overall, my goal for the next years is to make Cronhub into a comprehensive but simple scheduling tool for developers. I want to invest in the API so that other developers can build apps and workflows on top of Cronhub. I'm very passionate about the developer tools space and want to continue building cool stuff for this market.

Quick Demo

For people who like watching product demo gifs I recorded a gif yesterday to show off the product.

Also, I recorded a quick fun video if you like watching videos :)

In the meantime, if you're reading this, you might want to follow me on Twitter or upvote Cronhub on ProductHunt. I also have a mailing list where I share my learnings and thoughts on building a software business. If you're into it then you can subscribe here.

Thank you.