I’d like to propose a feature that, in my opinion, would significantly improve Xano’s capabilities around background processing and bring it more in line with modern, event-driven architectures.
Right now, Xano gives us two useful mechanisms:
Post Process, which allows functions to run immediately after an endpoint response (great for async/non-blocking flows)
Background Tasks, which allow recurring jobs
However, there is a clear gap: there is no native way to schedule a function to run at a specific point in time (i.e., no scheduler).
This has been mentioned in community posts going back 2–4 years, and while there are workarounds, they are far from ideal. The typical approach involves creating a database “queue” table, running a recurring background task to poll that table, executing pending jobs.
This approach feels quite outdated (it honestly reminds me of old PHP + cronjob patterns) and comes with several drawbacks:
Inefficient at scale (constant polling + DB reads)
Bulk/spiky execution patterns instead of smooth distribution over time
Lack of timing precision (execution depends on task intervals, not exact timestamps)
Additional complexity and maintenance (tables, polling logic, cleanup, retries, etc.)
Unnecessary resource usage, especially on the database layer
Proposed Solution
Instead of introducing a completely new system, my suggestion is to extend the existing “Post Process” feature.
Specifically, allow an optional field such as a “timestamp” (or scheduled_at) to be defined in Post Process.
If no timestamp is provided → behavior remains the same (execute immediately after response)
If a timestamp is provided → execution is deferred and triggered exactly at that time
Under the hood, this would rely on an internal Xano-managed queue, removing the need for developers to build and maintain their own scheduling systems.
Benefits
Precise scheduling (execution at a specific timestamp, not “best effort” intervals)
Better scalability (no polling, no bulk spikes)
Lower resource usage (no DB queue required)
Cleaner architecture (no custom schedulers, simpler backend logic)
More modern paradigm (event-driven, async-first design)
This would effectively turn Post Process into a more powerful async orchestration tool, covering both immediate background execution and delayed/scheduled execution without introducing additional complexity for developers.
I believe this would solve a long-standing gap in Xano and remove the need for fragile workarounds that don’t scale well.
Curious to hear what others think — and hopefully the Xano team might consider this direction.
FA