Trigger Periodic OpenWhisk Actions

Distributed “cron jobs” using the Alarm package

With serverless programming in general, and OpenWhisk in particular, actions run in response to an event. An event might be a web request, a database change, a sensor reading—the possibilities are endless.

But how about the situation where the action should run every so often? This post will cover how to set up a periodic trigger for your OpenWhisk actions, as if we had set up a “cron” schedule.

I’m assuming that you already have the wsk command-line tool set up to work with OpenWhisk. If not, you can nip off and do that now, I'll wait! Click the "Download OpenWhisk CLI" button on the OpenWhisk page for all the instructions you need.
Currently incubating in the Apache Software Foundation.

Rules and triggers

Let’s start with some glossary definitions:

  • package is a way of keeping actions grouped together; they can also have parameters that are available to all actions
  • action a serverless function
  • sequence more than one action, set up to run one after another, and with each action using the output of the previous action as its own input
  • trigger an event that can be responded to
  • rule wiring to link a trigger to an action or sequence
The components of OpenWhisk’s serverless platform. Image credit: Apache OpenWhisk™.

Still with me? What’s needed for our action to be automatically run at defined intervals is actually two things:

  1. the trigger to fire as often is required
  2. the rule to link that trigger to an action (or sequence)

The cron trigger

The trigger uses the /whisk.system/alarm/alarms feed that is built in to OpenWhisk. I'm showing a specific example here, but the package has excellent documentation if you want to adapt these examples to your own needs. The trickiest part by far is working out the cron syntax, and for that there’s

The trigger used here fires every five minutes, and it sends a list of tags as its payload. To create it, the command looks like this:

wsk trigger create five-mins-data --feed /whisk.system/alarms/alarm --param cron "*/5 * * * *" --param trigger_payload "{\"tags\": [\"cloudant\",\"pixiedust\"]}"

Once you create the trigger, you can see it in the output of wsk activation list when it fires (in this case, every five minutes). It’s a handy way to check if the trigger is firing as expected.

Note that once created, triggers can’t be updated. Instead, they need to be deleted with wsk trigger delete five-mins-data and then recreated.

The trigger_payload parameter will be passed into any action or sequence that this trigger is linked to by a rule. Speaking of which, it’s time to create a rule.

Link triggers to actions with rules

The trigger is up and firing — but it’s firing blanks until you attach it to something. To wire it up, you’ll create a rule and link it to an existing (packaged) action, like so:

wsk rule update five-mins-rule five-mins-data $MYPACKAGE/$MYACTION
wsk rule enable five-mins-rule

Rules can be updated, and if the rule doesn’t exist then wsk will silently create it. Hence, you’ll use the wsk update command here. The same update command also names a trigger and an action (or sequence), in that order. When the trigger fires, the action will be invoked. There can be many rules linking the same trigger to multiple actions.

Note that when a rule is changed, it will be automatically disabled. Check that the rule is enabled after creating or changing it, or it may not work!

The next time the trigger fires, the rule will cause the action to run — and we’ll see all three appearing in the output of wsk activation list.


Now that your trigger has been running, you might want to delete it so it doesn’t run perpetually. Similar to activations, to see a list of current rules run wsk trigger list. Then to delete your trigger, run:

wsk trigger delete five-mins-data

A similar process applies to rules. If you deleted the trigger in this example, it makes sense to delete the rule associated with it too.

Periodic triggers for serverless actions in the wild

The time-based approach available in OpenWhisk’s Alarm package is very handy for many applications. In one of my apps, I’m using this regular trigger to hit an API endpoint for a data source that doesn’t have webhooks available for when data changes. I can schedule this trigger as often or as infrequently as I like — and in fact the live application uses multiple of these “cron” triggers to fetch different tags on different frequencies.

What’s your use case? I’d love to hear about it, so leave me a comment. And of course, click the heart icon ♡ to tell me I should write more like this, if that’s the case!