Backend logic sometimes needs to run on a schedule rather than in response to a request. Common cases include nightly data exports, batch processing during off-peak hours, and recurring reports.
Scheduled jobs are the platform-managed way to run backend code on a recurring schedule. You declare which backend function should run and how often, and Wix runs it on that schedule. The job runs on the same infrastructure as the rest of the project's backend code, with the same access to platform APIs, data collections, and secrets.
Because the platform itself is the caller, a scheduled job runs with no current member. Platform methods that depend on caller identity, such as the Get Current Member method, shouldn't be used inside the job. The scheduler also doesn't pass any arguments to the function, so anything a job needs has to come from imported modules, secrets, or stored state.
Scheduled jobs are tied to the backend model used by Wix sites and Wix Blocks apps. Other paths use a different backend model or bring their own, and have to schedule recurring work differently:
- Sites: Declare scheduled jobs in a project-level configuration file alongside the rest of the site's backend code. Jobs run only on the published site. See Schedule Recurring Jobs in Extend Websites.
- Wix-managed headless projects: Don't expose scheduled jobs as a backend extension. Projects that need recurring backend work have to schedule it outside Wix and trigger it by calling an HTTP endpoint the project exposes.
- Self-managed headless projects: Run on infrastructure you manage, so recurring work is scheduled by whatever your chosen stack supports.
- Wix-managed apps: Don't expose scheduled jobs as a backend extension. Projects that need recurring backend work have to schedule it outside Wix and trigger it by calling an HTTP endpoint the project exposes.
- Self-managed apps: Run on infrastructure you manage, so recurring work is scheduled by whatever your chosen stack supports.
- Blocks apps: Don't ship their own scheduled jobs. A Blocks app could expose a backend function that the installing site can call. Then, to run on a schedule, the site would need to declare a scheduled job in its own backend code invoking the function.
- To run backend logic in response to an incoming request rather than on a schedule, see Frontend-to-Backend Communication.
- To run backend logic in response to a platform event, see Events.