Issue with Cron Job Timing in OpenWhisk Alarms | Community
Skip to main content
rxraj
rxraj
February 11, 2026
Solved

Issue with Cron Job Timing in OpenWhisk Alarms

  • February 11, 2026
  • 1 reply
  • 31 views

Hello,

We are encountering a challenge with the setup of cron jobs using the OpenWhisk Alarms feature, which is part of the Adobe App Builder Runtime.

Initially, we configured a trigger to invoke an action at 14:00 UTC as follows:

triggers:
  scheduleNightSync:
    feed: /whisk.system/alarms/alarm
    inputs:
      cron: 0 14 * * *
      timezone: UTC

However, due to a requirement change, we need to adjust this trigger time to 13:00 UTC.

 

To update the cron timing, we followed these steps:

1. Removed the existing trigger from the Runtime: `[aio rt:trigger:delete scheduleNightSync]`
2. Changed the cron schedule in the `app.config.yaml` file: `[cron: 0 13 * * *]`
3. Fully deployed the application: `[aio app deploy | aio app deploy --force-deploy]`
4. Retrieved the updated configuration of the trigger: `[aio rt:trigger:get scheduleNightSync]`. It shows the updated cron schedule: `{ "key": "cron", "value": "0 13 * * *" }`

Despite completing these steps, the trigger still invokes the action at 14:00 UTC instead of the intended 13:00 UTC.

 

I would appreciate any suggestions on how to resolve this issue. Thank you in advance for your assistance!

Best answer by AmitVishwakarma

Hi ​@rxraj ,
This is a known Adobe I/O Runtime bug: Alarms do not respect cron changes when you reuse the same trigger name, even if you delete and redeploy it. The alarm provider keeps the original schedule in its in‑memory cache.https://developer.adobe.com/app-builder/docs/resources/cron-jobs/

Because of that, your scheduleNightSync trigger is still firing with the original 0 14 * * *.

What you need to do

1.Use a new trigger name (and rule name) for the new time. For example in app.config.yaml:

triggers:
  scheduleNightSync_v2:
    feed: /whisk.system/alarms/alarm
    inputs:
      cron: "0 13 * * *"
      timezone: "UTC"

rules:
  scheduleNightSync_v2_rule:
    trigger: scheduleNightSync_v2
    action: <your-package>/<your-action>

2. Deploy with the new names: aio app deploy --force-deploy

3. Verify the new trigger: 

aio rt:trigger:get scheduleNightSync_v2
# check that cron = "0 13 * * *" and timezone = "UTC"

4. Optionally, clean up the old trigger/rule (they won’t be used anymore):

aio rt:rule:delete scheduleNightSync
aio rt:trigger:delete scheduleNightSync

Going forward: every time you change the cron (or other inputs) of an alarm trigger, give it a new, unique name in that workspace. That’s the only reliable workaround until the underlying Runtime issue (cannot update alarms in place) is fully fixed.https://developer.adobe.com/app-builder/docs/resources/cron-jobs/lesson3

Thanks,
Amit

1 reply

AmitVishwakarma
Community Advisor
AmitVishwakarmaCommunity AdvisorAccepted solution
Community Advisor
February 18, 2026

Hi ​@rxraj ,
This is a known Adobe I/O Runtime bug: Alarms do not respect cron changes when you reuse the same trigger name, even if you delete and redeploy it. The alarm provider keeps the original schedule in its in‑memory cache.https://developer.adobe.com/app-builder/docs/resources/cron-jobs/

Because of that, your scheduleNightSync trigger is still firing with the original 0 14 * * *.

What you need to do

1.Use a new trigger name (and rule name) for the new time. For example in app.config.yaml:

triggers:
  scheduleNightSync_v2:
    feed: /whisk.system/alarms/alarm
    inputs:
      cron: "0 13 * * *"
      timezone: "UTC"

rules:
  scheduleNightSync_v2_rule:
    trigger: scheduleNightSync_v2
    action: <your-package>/<your-action>

2. Deploy with the new names: aio app deploy --force-deploy

3. Verify the new trigger: 

aio rt:trigger:get scheduleNightSync_v2
# check that cron = "0 13 * * *" and timezone = "UTC"

4. Optionally, clean up the old trigger/rule (they won’t be used anymore):

aio rt:rule:delete scheduleNightSync
aio rt:trigger:delete scheduleNightSync

Going forward: every time you change the cron (or other inputs) of an alarm trigger, give it a new, unique name in that workspace. That’s the only reliable workaround until the underlying Runtime issue (cannot update alarms in place) is fully fixed.https://developer.adobe.com/app-builder/docs/resources/cron-jobs/lesson3

Thanks,
Amit

rxraj
rxrajAuthor
February 18, 2026

Thank you for the solution, ​@AmitVishwakarma .

We implemented this solution to create the new Alarm rule, and it worked successfully.

 

However, can we expect it to be included in future updates to change the cron schedule in existing rules?

AmitVishwakarma
Community Advisor
AmitVishwakarmaCommunity Advisor
Community Advisor
February 18, 2026

Hi ​@rxraj 
Thanks for confirming it worked.

As of today this is a limitation of the underlying Adobe I/O Runtime/OpenWhisk alarms implementation: changing the cron on an existing alarm trigger is not officially supported, and the safe pattern is to create a new trigger (i.e. new name) when the schedule changes.

There’s no public ETA that I can share for in‑place updates to alarm schedules. When/if this is supported, it will be reflected in the App Builder / Runtime release notes and the cron jobs documentation: https://developer.adobe.com/app-builder/docs/resources/cron-jobs/

 

If this behavior is a blocker for your project, I’d recommend raising it through Adobe Support (with your Org ID and workspace details) so it’s tracked as a feature request and can help prioritize a fix.

Thanks,
Amit

    Terms & ConditionsAccessibility statement

    Loading footer...