← Back to EasyCron.com

Mar 28, 2017

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.

Jan 20, 2017

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?

Jan 7, 2017

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.

Nov 10, 2015

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.

Nov 2, 2015

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

OVH network problem

Starting from Nov 2, 17:00 till now, OVH network problem is affecting EasyCron's service:



Oct 9, 2015

Domain on hold accident

We're very sorry for an accident happened during (about)
2015-10-08 16:00 UTC
2015-10-09 21:00 UTC.

During this period, our main domain easycron.com got a "Registrar-Hold" (ClientHold) status due to inaccurate whois data. This hold was set by the domain registrar enom (enom.com).

A "Registrar-Hold" (ClientHold) status means that all the resolution of the domain will be (and have to be) disabled by the registrar. Our direct domain registrar is namecheap.com, and its upstream provider is enom.com. The status change was done by enom.com, and namecheap was asked to stop the resolution of our domain.

We started to observe the abnormality at 2015-10-08 17:00 UTC. From that time, our website and API failed to respond, and our monitoring system sent out alert, though our cron job executing engine is independent to the DNS and still working fine.

One of our quick suspicions is, our DNS got a problem. But after a detailed check in it, we found nothing. So we fired several requests to our hosting (OVH) and registrar (namecheap) to consult what could be the problem.

We also noticed that easycron's whois data on namecheap is "ok" (actually we were badly misdirected by this info, the status on namecheap's whois query page is a "cache", not info in real time). So we didn't think about it's a domain issue.

After several hours of investigation, checking, testing, and chatting with namecheap, one of its colleagues said that he noticed that our domain was in "clientHold" status. I then check again with
and found that our domain is really under "Registrar-Hold" (ClientHold) status.

After knowing the root of the problem, we submitted a ticket to namecheap, and they said they have no control to the domain status and need to request enom to update that. After several back and forth, we still could not get the domain reactivated.

Seeing the inefficiency of waiting namecheap acting as intermediate between us and enom, we contacted whois@enom.com directly via email. It's 2015-10-09 17:00 UTC.

whois@enom.com responded with more useful progress than namecheap's ticket system. They (whois@enom.com) replied our emails in 2 hours, 1 hour. And at last, after we provided all needed statement/proof (electricity bill) of our data's accuracy/validity in our last email to them, it took another 3 hours to approve our new whois data and remove "Registrar-Hold" status. That means, if we provide all needed documents in the first email, we could get our domain back to live in 3 hrs. More optimistically, if we send an email with the proof to whois@enom.com directly right after we observed the problem, our domain may be back in 3 hrs, not 30 hrs.

Lessens learned (hope that they could help people to get their domains out of "Registar-Hold or ClientHold" quickly):

  • 1) check whois data with the tool on the website of the root registrar (in our case, enom) of your domain, not with the tool caching whois data result (in our case, namecheap).
  • 2) contact the root registrar directly (with all possible methods).
  • 3) in the first email, prepare all things, like updating detailed whois data, attaching electricity bill, etc.. Provide all information you think that is useful for approving your whois data. It will reduce the email rounds between you and the registrar, which means saving several hrs of time.
  • 4) in daily routines, check every email from whois email address immediately, respond and treat them seriously.

    In our case, we received whois update request from enom about 15 days ago, and we updated the data. But we didn't get any email (denial or approval) since that. Until 2015-10-07 20:00, they sent the denial email. This email is with "ticket" in its title. We don't have ticket system in our service, so we put the ticket emails (most of ticket emails reach our email box are generated by users' ticket systems responding to our email alerts) to secondary priority and handle them only at night. Without starting to handle these emails, the domain issue exploded! After 10 hrs of its last email alert, enom held our domain.

  • 5) publish the current status or issue fixing progress on twitter/facebook, etc.. This will help people understand what's going on, what to expect. And, you'll get supports from your users. They're more patient than you think and will make allowance for the situation. After experiencing these, you'll be thankful and keen to provide best products and services to all of your users.

In the end of the post, we have to say sorry again to all users of EasyCron. We'll try our best to prevent this kind of problem happen again.