← Back to EasyCron.com

Feb 3, 2019

Service malfunctioning during 2019-02-01 23:05 UTC to 2019-02-02 07:24 UTC

During 2019-02-01 23:05 UTC to 2019-02-02 07:24 UTC, we had an error with one of our core servers, which had caused our executor servers failing to execute cron jobs. The problem has been solved at 2019-02-02 07:25 UTC, and the system started working again since that.

We're investigating the root cause of the problem, and will enhance the whole system from the bottom up once the thorough investigation is done.

In the preliminary inspection, we found that the failure is related to partition space shortage caused by irrational disk partitioning of a pretty old CentOS. While Redis doing BIGSAVE to the partition, there was no enough space in the partition, so Redis kept doing BIGSAVE (as it's triggered by AOF file size). Finally both partition space and RAM were exhausted, and the server could only partly function during the failure time.

As a quick repair, we moved one of our Redis log servers to a new dedicated system with 4 times of RAM and 10 times of disk space.

Any missed cron jobs that should be run during the failure time have been executed (for one time) when the system was back to working again.

We're really sorry for the malfunctioning of the service. We will further investigate the whole failure and publish more information if necessary.

Nov 6, 2018

Use Different Timezone for Each Cron Job

Instead of using timezone from your EasyCron account for all cron jobs, from now on you may specify different timezone for each cron job.

We've just added two options that allow you to choose if you want to use the global timezone (the timezone from your EasyCron account) or specify a particular timezone for your cron job:

Specify different timezones for each of your cron jobs

In our API, associated methods (Add and Edit) also got two additional parameters (timezone_from, timezone) that implement this new feature.

To avoid confusion, all places (logs, failures, test run page, etc.) on our site showing date and times consequently have a timezone abbreviation appended:

Times Displayed with Abbreviation Timezone Names

Allowing specifying cron job timezone individually greatly improves the usability of our service in many use scenarios. Hope that you'll like it.

Nov 3, 2018

EasyCron New UI Launched

We're proud to say that recently we launched an entire new UI with functionality updates.

The front end of our site is now neat and could be loaded faster.

EasyCron New Front End

The back end also got a complete rebuild. Users can now easily click into category of "enabled", "disabled" cron jobs, or a particular group of cron jobs easily from the home page's left sidebar. In the cron job list page of any category or group, you may navigate cron jobs by page, search/reorder cron jobs. These new functionality and flexibility will greatly help you find and configure your cron jobs.

EasyCron New Back End

Our whole site (including front end and back end) is mobile friendly now. We introduced all necessary responsibility technologies to make the site look and work perfectly in mobile devices (from small screen cellphone to medium screen Xpad and large screen desktop).

EasyCron New Mobile Front End

EasyCron New Mobile Back End

Stay tuned, more exciting updates are coming :)

Mar 23, 2018

Output regexp matching

In some cases, you may want to determine the success (or failure) of cron job execution by the content of the output responded from your cron job script (not only by the HTTP code).

With the new feature we introduced today, you can now use regexp to match the output (HTTP message body), and then judge if the cron job execution is successful.

Output regexp matching

As you can see in the screenshot, there are 3 options you could choose from as the condition for your execution to be considered as succeeded or failed:

  • When the HTTP Status is 2xx, consider succeeded. (This is the default option)
  • When the HTTP Status is 2xx, consider succeeded if the HTTP message body matches a specified regular expression.
  • When the HTTP Status is 2xx, consider failed if the HTTP message body matches a specified regular expression.

After above 3 new options were added, the complete rules for judging success or failure are:

  1. Consider failed when the HTTP Status is NOT 2xx (e.g. 200, 201, etc.).
  2. When the HTTP Status is 2xx, check above 3 options.

For the sake of simplicity and matching performance, we use Google re2 as the regexp engine.

Hope that the new feature rocks for you.

Jan 21, 2018

Execution logs enhanced

We recently made some changes to the way we trim and save execution logs.

In the past, in additional to cron job ID, scheduled time to execute, trigger time, done time, cost time and HTTP status, up to 10 KB of output (includes HTTP headers and HTTP message body) responded from your cron job script will be saved for each execution.

Now, the log output part saved in new way will contain:

  • up to 10 KB of HTTP headers, plus
  • up to 20 KB (5 KB for individual plans) of head of the HTTP message body, plus
  • a line of text (example: 1200 Characters Stripped) inserted by EasyCron indicating how many characters were stripped (if the whole HTTP message body is longer than the log length limit of your plan), plus
  • up to 20 KB (5 KB for individual plans) of tail of the HTTP message body.

We hope that the new logs will provide more information you need and help you better understand the overall response from your cron job scripts.

Jan 5, 2018

Cron job execution tracking

Want to know if your cron job has been triggered or not before it's done and its log is saved? Now you're able to do it with our new feature "cron job execution tracking".

With cron job execution tracking, when your cron job has been triggered and is running, your will see an "executing" line immediately in the logs of this cron job telling you that it's executing, like screenshot below:

Cron job execution tracking

This is extremely useful for your awareness of that the cron job has been successfully fired. So that you don't need to worry about you miss the cron job trigger time.

Jun 13, 2017

Datacenter hardware maintenance

Our dedicated servers provider OVH (ovh.com) has sent us an alert about a hardware (electrical reboot) replacement that will happen on June 14, at 6:00AM EDT and last about 1 to 1.5 hour:

This hardware replacement will affect one of our core servers which is relied by our other servers to perform EasyCron's service.

As a result, during the intervention, our service will be interrupted. And the service will recover automatically once the maintenance is finished and the server is booted again.

From information we got, the replacement of electric part could do no impact to the server:
or cause a variable length of downtime (from dozen of minutes to 1 hour):

There is nothing we can do now to 100% avoid this service interrupt. But we're working on a solution to have our HA (high availability) strategy cover this server, so that in the future if similar maintenance happen again, our service will not be affected.

As a remedy, EasyCron will fire those cron jobs that have missed executions during the maintenance for *one* time after the service back to normal. That means, your affected cron jobs will get triggered for one time after our server is up again.

We're really sorry for the inconvenience that will be caused by this server maintenance.


Our server's downtime started from
June 14th, 6:39 AM EDT, and ended on
June 14th, 7:14 AM EDT, totally lasted
35 minutes.
Our service fully backed to normal at
June 14th, 7:20 AM EDT.