This is a simple application that triggers GET requests periodically. I'm currently using it to trigger the sending of emails of another of my apps (http://mailaday.com/ - checks due emails every 5 minutes).
This is currently very bare-bones but I'm publishing it here just to see if people are interested in something like this.
I guess this kind of services may be useful for developers which do not have access to system crontabs but still want to periodically run some tasks (which they can program to be ran from a URL endpoint which cronbeats will send a GET request to), like doing db backups, sending emails, clean the database, etc.
I have a free version which allows users to create 10 cronbeats, but if it finds interest, I'll find motivation to build the code to the "pro" versions..
I wouldn’t use a cron service because of the security problems. cron running locally means I can protect the scripts from getting executed when I don’t want them run. If this service can send requests to run scripts anyone can send the same request.
With cloud hosting at $5/mo with shell access any developer who doesn’t have access to their crontabs should fix that problem.
I also agree that most developers are easily able to set up a cronjob locally. However, cronjobs may easily fail to start or may not finish on time. In the future I would like to add a way for users to add retries, timeouts, and grace periods for completion, or else they get alerted.
The guy(s) at https://healthchecks.io/ do the job of monitoring the job completion but do not trigger the job itself. I'm looking to see if someone has both the needs (to start the job, and to check its completion)..
> If this service can send requests to run scripts anyone can send the same request.
I thought of that. A easy fix would be to send a token in the url query, and validate that token in the user's webapp's view..
I don't experience problems with cron itself failing to start jobs, but it doesn't have any monitoring built-in. Solutions exist for that, including wrapping cron scripts to notify or log when they start and stop.
Implementing retries, timeouts, etc. for jobs you initiate remotely over HTTP GET requests, and using a token for validating access, seems like a lot more integration at the customer side than just using cron.
Enforcing timeouts, or preventing them, means changing the web server (Apache) and runtime system (e.g. mod_php) to allow a process to run for longer than the default time. If I have access to Apache and PHP config I also have access to the crontab.
I use cron with HTTP GET requests locally, run with curl so I can set a timeout and capture the output. Apache restricts those requests to localhost, so they can't get initiated remotely. I have a simple wrapper that logs when jobs start and finish, and a monitoring page that shows last run time and success/fail status. Every job has an associated estimated time it should run so the monitor can show jobs that ran too long.
4 comments
[ 4.4 ms ] story [ 17.0 ms ] threadThis is currently very bare-bones but I'm publishing it here just to see if people are interested in something like this.
I guess this kind of services may be useful for developers which do not have access to system crontabs but still want to periodically run some tasks (which they can program to be ran from a URL endpoint which cronbeats will send a GET request to), like doing db backups, sending emails, clean the database, etc.
I have a free version which allows users to create 10 cronbeats, but if it finds interest, I'll find motivation to build the code to the "pro" versions..
I wouldn’t use a cron service because of the security problems. cron running locally means I can protect the scripts from getting executed when I don’t want them run. If this service can send requests to run scripts anyone can send the same request.
With cloud hosting at $5/mo with shell access any developer who doesn’t have access to their crontabs should fix that problem.
The guy(s) at https://healthchecks.io/ do the job of monitoring the job completion but do not trigger the job itself. I'm looking to see if someone has both the needs (to start the job, and to check its completion)..
> If this service can send requests to run scripts anyone can send the same request.
I thought of that. A easy fix would be to send a token in the url query, and validate that token in the user's webapp's view..
Thanks for the feedback!
Implementing retries, timeouts, etc. for jobs you initiate remotely over HTTP GET requests, and using a token for validating access, seems like a lot more integration at the customer side than just using cron.
Enforcing timeouts, or preventing them, means changing the web server (Apache) and runtime system (e.g. mod_php) to allow a process to run for longer than the default time. If I have access to Apache and PHP config I also have access to the crontab.
I use cron with HTTP GET requests locally, run with curl so I can set a timeout and capture the output. Apache restricts those requests to localhost, so they can't get initiated remotely. I have a simple wrapper that logs when jobs start and finish, and a monitoring page that shows last run time and success/fail status. Every job has an associated estimated time it should run so the monitor can show jobs that ran too long.