FetchqCRON

Executing repeatable jobs is at the core of most IT projects. From following up a few days after a user signs up, to repetitive cleaning or caching procedures. FetchqCRON provides time-based execution as a service, on Heroku or on-premise via Docker. FOR FREE.

FetchqCRON

Run smart CRON jobs

I started to work on the FetchqCRON project when I realized I was re-implementing the architecture around repeatable jobs over and over, project by project.

And you donโ€™t like to repeat yourself, right?

Letโ€™s start with an example:
An ideal scenario to handle users signup would be:

  1. sign the user up
  2. ๐Ÿ‘‰ in 2 hours, check on the user to see if he/she confirmed his/her email
  3. thank the user

Point n.1 and n.3 are up to your route handler, FetchqCRON lets you solve point n.2 with a simple REST call that plans the execution of a webhook in 2 hours.

You can easily configure how to execute the webhook. It can be any kind of REST call where you are in control of headers and body structure, or it can be a GraphQL query or mutation.

Wanna dig into the documentation?
๐Ÿ‘‰ https://cron.fetchq.com

How to set up a Webhook job:

Here is an example call that sets up a task with 2 hours delay. It will post to a given URL, providing custom headers:

/* post://fetchq-cron-instance.com/api/v1/cron */

{
  "group_name": "verify-email",
  "task_name": "user123",
  "schedule": {
    "method": "delay",
    "value": "+2 hours"
    },
  "action": {
    "method": "webhook",
    "request": {
      "type": "rest",
      "method": "POST",
      "url": "http://my-web-app.com/webhooks/verify-email/user123".
      "headers": {
        "content-type": "application/json",
        "authorization": "Bearer xxx"
      }
    }
  }
}

The target webhook should respond ย statusCode=200 in order to yield a successful run. In such a case, the webhook will be triggered again in 2 more hours.

Successfull webhook execution:
statusCode = 200

In case any error should happen, the action is re-attempted for a configurable amount of times before the system gives up, every failing run is duly logged for full traceability.

Webhooks can reschedule the job:

The target webhook can interact back with the scheduler, providing active feedback and re-programming the execution plan:

/* webhook's response: */
{
  "success": true,
  "schedule": {
    "method": "delay",
    "value": "+999y",
  },
  "logs": [{
    "message": "user email was successfully confirmed"
  }]
}

This kind of response will re-schedule the next execution 999 years in the future. Itโ€™s just a hacky way to kill the task. We have more features coming up soon. ๐Ÿ˜Š

It also writes a log entry in the taskโ€™s history. FetchqCRON keeps a detailed execution log where you can trace any activity that happened to a task.

Main Features:

  • setup time-based jobs via RESTful API
  • setup time-based jobs via WebConsole
  • access detailed logs per task/group/server
  • scale up the job workers for parallel execution
  • run the server in API only mode (good for micro-service architecture)
  • fine-grained authorization via JWT (*)

(*) in development

Job Types:

  • webhook
  • AWS Lambda functions (*)
  • Docker functions (*)

(*) in development

Try it out on Heroku

๐Ÿ˜Ž Wanna try it?
It takes just a few minutes to run your own instance in Heroku:

deploy on Heroku

๐Ÿค“ Feeling adventurous?
We have you covered, click here to run the cloud-based development environment:

Open in GitPod

Feedback & Contribute

Read the Documentation:
๐Ÿ“– https://cron.fetchq.com

Please come and give your feedback on our ProductHunt page:
๐Ÿ‘‰ https://www.producthunt.com/posts/fetchq-cron

And donโ€™t forget to give us a star on GitHub:
โญ https://github.com/marcopeg/fetchq-cron