Since 2026-08-23 ~22:58 UTC, on one Cloud project. Three symptoms, probably one cause.
1. No scheduled flow fires. All five schedule-triggered flows in the project have missed every firing since then, while showing ENABLED + published. The clearest signal is a 5-minute cron (wST5gpLSszYQ8tPPMXAjq, 0/5 * * * *), last run 22:58:52. In the ~14 hours since it has produced one run, at 12:53:47, off-boundary — then missed 12:55, 13:00, 13:05, 13:10 and 13:15. No run rows are created at all.
2. Webhook runs strand in QUEUED, out of order. Batches sit queued indefinitely while runs enqueued later, on the same flows, start and complete normally. Example: FD38AC8NEOwrip6YSO6sV (queued 13:01:39) was still queued at 13:17 while runs from 13:02:31 had finished. One run has been queued since 00:14 UTC. Callers waiting on a stranded subflow eventually fail with Subflow execution failed after very long waits — we have entry-point runs with recorded durations of 1775s, 8323s and 46239s.
3. Re-running a queued run loses its trigger payload — the work is destroyed, not recovered. Selecting the stranded runs and using re-run produced runs whose trigger.output is null. Downstream everything then fails on empty input: code steps throw Invalid inputs: `inputs` or `inputs.body` is undefined, and the Zoho piece posts {"data": ""} and gets 400 INVALID_DATA.
This affects webhook-triggered entry-point runs too, not just subflows — aZmAOEqnoQoYYwLGC3wNh is a webhook run with a null trigger payload, while 6Mjoj442zhlOndsBmiT7P, which was never re-run, has its full payload intact. Since these runs had never executed, the payload presumably still lived in the queue and was not carried onto the re-run.
That makes re-run unsafe as a recovery path for queued work, and it silently loses data.
Other observations: no FAILED / TIMEOUT / INTERNAL_ERROR / QUOTA_EXCEEDED rows for the scheduled flows — the runs are simply never created. Nothing was edited, republished or re-enabled near the onset. Our plan has unlimited credits, so no task cap is involved. ap_list_runs via the API intermittently returns canceling statement due to statement timeout. status.activepieces.com has shown operational throughout.
We are holding off on republishing the scheduled flows so as not to destroy the reproduction. Happy to provide full run IDs, timestamps and traces.