Multiple Users support is added

You may now add multiple users to your EasyCron account if you're under an Enterprise plan (either paid or trial). The additional users are called subusers.

As an admin to your EasyCron account, you can click on the "subusers" link in the top menu to access the subuser list. There you may add/edit/delete subusers in your account.

Access Subusers Page

By clicking the "Add Subuser" button on the subusers page, you may enter an email address to create a subuser, then an email with a generated password will be sent to the email address.

"Add Subuser" Button

Enter an Email Address to Create a Subuser

After receiving the email, the subuser can login with the email address and the password. Once logs in, he or she can update the login credential (email address and password) at the user settings page.

A subuser can only add/edit/delete/view cron jobs and groups currently. Payment method, orders, billing and affiliate information, and API are not accessible nor editable by subusers.

The timezone of the account can be viewed but can not be changed by a subuser. It will help assure the consistency of the timezone in which the cron job's execution times are calculated and avoid any confusion.

If you have any advice on the new feature, please contact us. Thanks.

Two-factor authentication for securing your account

EasyCron adopted two-factor authentication (2FA) today. From now on, your EasyCron account and cron jobs will be protected by an extra layer of security means if you choose to enable the 2FA for your account.

If you're a new user, you can choose to go to the 2FA setting page to enable it when you're adding an email and password to your account.

Enable 2FA after Adding Email and Password

For any user who has completed registration, you can go to the 2FA setting page directly to enable 2FA.

2FA Setting

Once you enable 2FA, next time when you login, an extra 2FA code field will be prompted, you can simply find a 6-digit 2FA code on your cellphone to fill it.

Login with 2FA

Example 2FA Code

What we integrated for generating 2FA code are 2FA authenticator apps. Some recommended apps are: Authy, Google Authenticator and Microsoft Authenticator.

One-time cron job

Running one-off cron jobs is necessary in many scenarios, such as triggering a one-time alarm, handling subsequent processing after an event, etc..

In standard implementations of cron, the year field is not included in cron expression. Without introducing new tool (such as "at" command), scheduling a one-off cron job could be troublesome and confusing under those circumstances.

The bother involves adding a cron job and waiting for it to be triggered, and then "remembering" to delete it manually on time before next year's execution. Some may use an automatic method to delete the cron job once it's executed, but deleting it automatically could create a false impression that the cron job was never added and executed.

To completely solve the problem, free our users from all those hassles they could encounter and let them can still utilize the power of cron expression, EasyCron added the year field to the cron expression. The implementation is clean, causing no confusion, and no additional action is required to take after cron job execution to achieve running cron job once.

Furthermore, after the cron job is executed, just as inspecting a regular cron job, you could check a one-time cron job's execution result on EasyCron at any time to troubleshoot possible issue.

We hope that the new capabilities that the "year" field brought help.

Added "year" field support in cron expression

We're exited to announce that EasyCron supports "year" field in cron expression now. By appending a year field to the end of your cron expression, EasyCron will only run your cron job during the specified year(s).

In the year field, you could use values "1970" to "2099" with special characters ", - * /".

For more information about "year" field details, please refer to our cron expression guide.

Beside using cron expression directly, you could also specify execution year(s) by choosing years manually in our cron job creating/editing UI too as the screenshot below.

Choose Execution Years Manually for Cron Job

Slack Notifications for Cron Jobs

Considering many developers and cron job users use Slack heavily as communication tool in their daily work, we added Slack notification to our service.

Setting up Slack notifications for your cron jobs is easy. Here are the steps it will take:

1. In the cron job creating/editing form -> tab "Notifications" -> "Slack", choose the notification timings and the notifying sensitivity,
2. following the guide at Slack to get a URL (with a format of https://hooks.slack.com/services/xxx/yyy/zzz), and paste this URL into the "Slack URL" field. The Slack notification part is done.

Below is a screenshot for Slack notification interface:

Slack Notifications for Cron Job

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.

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.

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

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.

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.

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.

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:
http://status.ovh.net/?do=details&id=14704&edit=yep

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:
http://status.ovh.net/?do=details&id=14521
or cause a variable length of downtime (from dozen of minutes to 1 hour):
http://status.ovh.net/?do=details&id=14437
http://status.ovh.net/?do=details&id=14530

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.

UPDATE:

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.

Custom cron job timeout

Today we added a new feature to EasyCron - customizing cron job timeout.

In our previous cron job executing program, we always used your plan's default timeout as timeout limit. But in a few situations, you may want to change the timeout setting.

For example, if you don't want your cron job to run overlappingly, instead of setting max execution time in your script, you could also set the timeout limit at EasyCron. Once the configured timeout is reached, EasyCron will disconnect the connection between itself and your server, and your cron job script could detect the client side abortion and terminate the execution, so next execution could come without conflicting with previous execution(s).

Another possible use case for custom timeout is, if you know the legitimate maximum execution time of your cron job script/program, you may want to restrict the execution to a specific duration, so that any unexpected long time execution will be cancelled then.

Other uses include but not limit to, if you're going to use EasyCron as a monitoring service, you could set a deadline to the max response time cost; preventing proxy timeout, etc..

Custom cron job timeout

We hope that you could find this new feature useful.

Email notification optimization

As too many emails sending out from EasyCron has resulted in some problems, we has reduced the amount of email notices by changing the email notice triggering mechanism.

The main problems caused by frequently emailing are:

1) Many email service providers deem us as SPAM sender, block our emails (or/and IPs) constantly. This has brought big trouble to EasyCron and our users. For example, many expired users could not receive expiry email notices and didn't renew their accounts on time; some crucial cron jobs failed but didn't receive attention, and so on.

2) Some users' email box were filled up by emails sent by us.

3) The credit and authority of our domain and IPs descends as black listing done by other parties.

4) Our email server keeps being hit by huge amount of bounced emails from recipients.

Now EasyCron sends out email notices only when:

1) starts failing, or

2) returns to success from failure.

That is to say, if your cron job fails consecutively for more than one time, only one failure email notice will be sent to you.

You could also specify a "sensitivity" setting to configure only after how many consecutive failures that the failure notice will get sent.

Email notification and failure threshold

If in some cases, you really need to be notified for each failure or execution of your cron job, you could utilize the "webhook" feature.

Placeholders you could use in cron job URL

EasyCron added placeholder support in cron job URL today.

You could use placeholders:
__RANDOM__
__TIMESTAMP__
in your cron job URL.

__RANDOM__ will be replaced with a random 12-digit integer when your cron job is fired.
And __TIMESTAMP__ will be replaced with unix timestamp.

For example, URL
http://www.example.com?__RANDOM__
could finally be http://www.example.com?123456789000 when it's fired.

Random integer or timestamp in URL will prevent EasyCron's requests from hitting cache in your proxy or server.

EasyCron now supports sending webhook requests after cron job executions

Making a webhook request after cron job execution could be useful for notification or chaining other actions together after a cron job script/program does its work.

From now on, EasyCron starts supporting webhook request after cron job execution. Along the request, users can choose to send all or some of the following fields:

• Cron Job ID (will be received in your webhook script as parameter "cron_job_id")
• Cron Job Name (as parameter "cron_job_name")
• Cron Job URL (as parameter "cron_job_url")
• Cron Job Execution Status (as parameter "cron_job_execution_status". "Success" or "Failure")
• Cron Job Execution Error (as parameter "cron_job_execution_error". Will be empty when execution succeeds)

Configure webhook request after executions of your cron job

You could also choose a HTTP method to make the request from GET, POST, HEAD, PUT, PATCH, DELETE, CONNECT, OPTIONS and TRACE.

As everybody knows, email and maybe a few other contact methods (SMS, Push message, etc.) are not very dependable ways for notification. By using the webhook mechanism, users can do a more reliable notification in their webhook target script (Even sending emails to themselves from their own email address has higher arrival rate). And more than this, users can actually do almost anything in the webhook script. This could greatly extend the post-execution functionality of EasyCron.

Welcome to share how the webhook feature help you and simplify your work in the comments.

Goodbye "Engine". Welcome "Execution Per Day (EPD)".

Goodbye "Engine". Welcome "Execution Per Day (EPD)".

Since early 2014, we had been using "Engine" as our resource indicator representing cron job resource occupation. Today, we took it out from our system and replaced it with a new indicator "Execution Per Day (EPD)".

"Engine" is an abstract concept. There is no counterpart in real world that can be converted to it easily. Therefore, it has caused much confusion to our users, and consequently, much effort of ours to explain this concept to our users.

Quite differently, "Execution Per Day (EPD)" is natively intelligible. Beyond doubt, it's a life saver for EasyCron users and us :)

Actually, "Engine" has a simple calculation formula:
Engines = ceil (execution times per year / 1000)

And EPD got this one:
EPDs = execution times per day

There's not much difference? Right?

Customize your HTTP method and headers for your cron job requests

Happy New Year!

EasyCron used to have a "posts" and "cookies" field in the cron job settings which are for posting content and setting cookies for the HTTP requests sent to your server.

Now, in order to follow the HTTP standards and conventions, we've added a new feature - HTTP method and header customization - to our cron job setting.

As a result, the previous existing "posts" field is integrated with POST, PUT and PATCH method. And the previous existing "cookies" field will retire at 6:00 AM UTC, on Jan 14, 2017.

From now on, you can simply customize the HTTP method (from GET, POST, HEAD, PUT, PATCH, DELETE, CONNECT, OPTIONS and TRACE) and headers for your cron job requests at:

Customize HTTP method and headers for your cron job requests

If you have any longing feature that you want to have in EasyCron, please send us a message at our message page. We will always listen to our users at the first place.

Exporting Cron Jobs in EasyCron

We're happy to announce a new feature which is very useful and can keep our users' mind in peace: Cron Job Exporting.

Now you could down a full backup of your cron jobs added in EasyCron with several clicks.

To do it, just log in and go to "My Account" page, and then click on "Export Cron Jobs" tab, click on "Export my cron jobs" link. A CSV (Comma-Separated Values) file including all your cron job details will be downloaded to your computer.

Currently, cron job details of

• Cron Job Name,
• Expression,
• URL,
• Email Me (notification setting),
• Log (execution logging setting),
• Cookies (cookie variable names and values),
• POST (post variable names and values),
• Status (cron job status)

are included in the CSV file.

Drop us a line if you have any advice for the new feature.

OVH network problem solved

From Nov 2, 17:00 UTC to Nov 2, 22:00 UTC, Our hosting company (OVH, https://twitter.com/ovh_support_en/with_replies) encountered a network problem (fibre-optic cable broken). EasyCron was having slow connections to the internet during the cable fault.

This network issue has caused many of our users' cron jobs timing out and the loading speed of our site slowing down.

We're really sorry for the problem and any inconvenience brought.

Now OVH has fixed the problem, and EasyCron was back to normal since Nov 2, 22:00 UTC.

OVH has a page with the fixing progress of the issue posted at: http://status.ovh.com/?do=details&id=11304

To get latest updates about news from EasyCron, please follow our twitter @EasyCron