Email Subscription UI Update

Recently, we simplified our newsletter subscription system and added neccessary detailed list of email types we will send and our users are supposed to receive.

Previous Email Subscription

New Email Subscription

As shown in the screenshots, all newsletter types were merged to one type of email notification "Updates". And 2 implicit types of email sending "account information" and "cron job information" were made explict.

These UI changes will help our users understand what kinds of emails they will receive from EasyCron, what are unsubscribable and what are mandatory to receive if they decide to use our service.

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.