Category: Forge / Scheduled triggers Environments affected: development and staging (same app, both reproduced) Product: Jira Cloud
Summary
A fiveMinute scheduled trigger ran normally, then stopped invoking with no error, no log line, and no change to the app. Four documented remediations — including the manifest-change lever the reference explicitly says recreates all triggers — had no effect. The same behaviour then reproduced in a freshly installed staging environment. Roughly 36 hours later the trigger began firing again on its normal cadence, without any deliberate intervention on my side.
Everything else in the app stayed healthy throughout: web triggers were invoked normally, storage read and wrote, the admin page rendered, the resolvers responded. Only the scheduled trigger stopped.
I’m reporting this because the failure is silent. There is no error to catch, no failed invocation to observe, and nothing in the logs. An app that depends on a scheduled trigger for correctness has no way to know it has stopped.
Timeline (all times UTC)
Development environment
| Time | Event |
|---|---|
| 2026-08-08 22:42:47 | Last successful sweep. Normal cadence up to this point |
| — | No further invocations. No errors, no log output |
| 2026-08-09 (morning) | Deployed unrelated code change (v4.4.0). No resumption |
| 2026-08-09 08:52:48 | forge install --upgrade. No-op, no resumption |
| 2026-08-09 08:55:19 | forge uninstall |
| 2026-08-09 08:56:26 | forge install — fresh install, storage wiped. No resumption |
| 2026-08-09 11:01:41 | Renamed the scheduledTrigger module key and redeployed (v4.5.0). No resumption |
The manifest reference states that any change to a scheduled triggers module recreates all triggers and resets their start times. That did not happen here.
Staging environment (clean install, to rule out environment-specific state)
| Time | Event |
|---|---|
| 2026-08-09 13:12:04 | Installed |
| 2026-08-09 13:27:23 | Sweep ran |
| 2026-08-09 13:32:22 | Sweep ran |
| 2026-08-09 13:37:20 | Sweep ran |
| — | Stopped. No further invocations |
I re-checked staging after a deliberate delay to rule out log-ingestion lag.
Three invocations on the correct five-minute cadence, from a clean install, rules out a configuration fault: the manifest, the module key, the function binding and the interval are all demonstrably correct, or it would never have fired at all.
Resumption
| Time | Event |
|---|---|
| 2026-08-10 / 11 | The trigger began firing again on its ~5 minute cadence |
I did not fix it. Redeploys of unrelated work may have recreated it, or a platform-side condition cleared. I cannot distinguish between those from the outside, which is part of the problem.
Manifest
yaml
scheduledTrigger:
- key: retry-sweep-v2
function: sweep
interval: fiveMinute
(The key shown is post-rename; the original key produced identical behaviour.)
Why this matters beyond my app
My app uses the scheduled trigger as a safety net: work that could not be completed on first attempt is queued and retried on a schedule. A silently dead scheduler means the queue simply stops draining, and neither the app nor the customer’s administrator has any signal that anything is wrong.
I have since reworked the design so the scheduler is no longer the primary mechanism — the same work now also happens opportunistically on inbound traffic, with the scheduled sweep demoted to a backstop and a manual trigger as operator fallback. I’d suggest any app relying on scheduled triggers for correctness consider the same, which is why I’m posting rather than just working around it.
Intermittent-and-silent is a worse failure mode than permanently-broken. A trigger that stays dead gets noticed; one that dies for a day and quietly comes back leaves a hole in the data that nobody ever looks for.
Questions
- Is there a known platform-side condition — regional or otherwise — that can stop scheduled trigger invocation without surfacing an error?
- Is there any way for an app to detect that its own scheduled trigger is no longer being invoked, other than recording its last run in storage and inferring staleness? That’s what I do now, but it is inference, not a platform signal.
- The manifest reference says changing a scheduled triggers module recreates all triggers and resets start times. Under what circumstances does that not apply? It did not apply here, across a key rename and a full uninstall/reinstall.
- Is there a supported way to force recreation of a scheduled trigger for an installation, short of uninstalling?
Happy to supply app ID, installation ID and exact invocation IDs privately if that helps narrow it down.