Run a function on a schedule
Attach one or more cron schedules to a function so it runs without being called.
Prerequisites
- An existing function in an app.
- An organization owner or admin account, or another cloud user with access to the site.
Add a schedule
Schedules are written through the function itself.
- REST API
- TaruviBase Console
/api/apps/$TARUVI_APP_SLUG/functions/$FUNCTION_SLUG/curl -X PATCH "$TARUVI_SITE_URL/api/apps/$TARUVI_APP_SLUG/functions/$FUNCTION_SLUG/" \
-H "Authorization: Api-Key $TARUVI_API_KEY" \
-H "Content-Type: application/json" \
--data-binary @- <<'JSON'
{
"schedules": [
{
"cron_expression": "0 9 * * 1",
"schedule_params": {
"report": "weekly"
},
"is_active": true
}
]
}
JSON
200Returns the function with its schedules. Each schedule creates its own periodic task.
- Open the app and select Functions.
- Open the function and select Edit.
- Add a schedule with its Cron Expression and Schedule Parameters (JSON), then save.
Schedules are not available in the JavaScript or Python SDKs.
Write the cron expression
A schedule uses a five-part cron expression:
minute hour day-of-month month day-of-week
| Expression | Runs |
|---|---|
0 9 * * 1 | Every Monday at 09:00 |
*/15 * * * * | Every fifteen minutes |
0 0 1 * * | At midnight on the first of each month |
30 6 * * 1-5 | Weekdays at 06:30 |
An expression with the wrong number of parts, or one cron cannot parse, is rejected when you save.
Give each schedule its own parameters
A function can carry several schedules, each with its own expression and its own
schedule_params. Those parameters reach the function as params, exactly as if
a caller had supplied them.
This lets one function serve several jobs — a daily summary and a weekly summary, say — without duplicating the code:
{
"schedules": [
{"cron_expression": "0 7 * * *", "schedule_params": {"period": "daily"}, "is_active": true},
{"cron_expression": "0 8 * * 1", "schedule_params": {"period": "weekly"}, "is_active": true}
]
}
Turn a schedule off
Set is_active to false on the schedule. An inactive schedule stays on the
function and stops running; the platform skips it and records why. Use this in
preference to deleting a schedule you may want back.
Deleting the function deletes its schedules.
Understand how a scheduled run differs
Scheduled runs are not the same as calls to the execute endpoint, in three ways that matter:
- They run as the function's creator, not as whoever set up the schedule. If that user's permissions change, the scheduled run's reach changes with them.
- Filter conditions do not apply. They are evaluated only for event-triggered executions, so a schedule always runs.
- They are always asynchronous. There is no caller waiting, so the result is collected from the invocation record rather than returned.
Each scheduled run creates an invocation record with a trigger type of
schedule, which is how you tell scheduled activity from API traffic.
Verify
Wait for the next scheduled time, then check the function's runs. A record with
trigger type schedule confirms the schedule fired.
To test the logic without waiting, execute the function directly with the same parameters the schedule supplies.