Hi team — same symptom as a recent thread here where switching from a round cron expression to an offset-minute one fixed it.
Project ID: 69fa56560037c7843a85
Region: Frankfurt (fra)
Functions affected:
process-whatsapp-outbox — cron */5 * * * . Fired reliably every 5 minutes for months, then stopped completely. Last scheduled execution: 2026-08-17 20:48 UTC, nothing since. In the API object, scheduleNext and schedulePrevious are both null while enabled: true, schedule: "/5 * * * *", and the active deployment is ready. Manual/HTTP executions of this same function succeed every time — only the schedule is dead. This started right after a few failed GitHub (VCS) deployments on it.
wa-drain-ticker — a brand-new, dependency-light function I created to test, also */5 * * * *, enabled: true, deployment ready. It has been live for ~20 minutes with 0 executions — its schedule never armed at all.
Functions that DO work (same project):
get-tenant-by-slug — cron */2 * * * *, firing normally every 2 minutes (e.g. 00:40:53, 00:44:54 UTC today).
So the scheduler clearly isn't down project-wide — it just seems to not pick up new or recently-changed schedules.
Already tried on process-whatsapp-outbox (none restored the schedule):
Fresh deployment, activated (build ready)
Changing the schedule via API (*/5 → */3 → */5, confirmed the value actually changes)
Full disable → re-enable
Creating the brand-new function above
I've now changed wa-drain-ticker to 7,19,31,43,55 * * * * (offset minutes instead of */N) to test the workaround from the earlier thread.
Questions:
Is there a known issue where new/updated schedules don't get registered (possibly triggered by failed VCS deployments)?
Is there a way to force a schedule to re-register without deleting and recreating the function?
Any fix for process-whatsapp-outbox specifically, since its schedule record seems stuck?
Thanks!
