Queues
Queues are the final aspect of Payload's Jobs Queue and deal with how to run your jobs. Up to this point, all we've covered is how to queue up jobs to run, but so far, we aren't actually running any jobs.
When you go to run jobs, Payload will query for any jobs that are added to the queue and then run them. By default, all queued jobs are added to the default
queue.
But, imagine if you wanted to have some jobs that run nightly, and other jobs which should run every five minutes.
By specifying the queue
name when you queue a new job using payload.jobs.queue()
, you can queue certain jobs with queue: 'nightly'
, and other jobs can be left as the default queue.
Then, you could configure two different runner strategies:
- A
cron
that runs nightly, querying for jobs added to thenightly
queue - Another that runs any jobs that were added to the
default
queue every ~5 minutes or so
Executing jobs
As mentioned above, you can queue jobs, but the jobs won't run unless a worker picks up your jobs and runs them. This can be done in four ways:
Cron jobs
You can use the jobs.autoRun
property to configure cron jobs:
Endpoint
You can execute jobs by making a fetch request to the /api/payload-jobs/run
endpoint:
This endpoint is automatically mounted for you and is helpful in conjunction with serverless platforms like Vercel, where you might want to use Vercel Cron to invoke a serverless function that executes your jobs.
Vercel Cron Example
If you're deploying on Vercel, you can add a vercel.json
file in the root of your project that configures Vercel Cron to invoke the run
endpoint on a cron schedule.
Here's an example of what this file will look like:
The configuration above schedules the endpoint /api/payload-jobs/run
to be invoked every 5 minutes.
The last step will be to secure your run
endpoint so that only the proper users can invoke the runner.
To do this, you can set an environment variable on your Vercel project called CRON_SECRET
, which should be a random string—ideally 16 characters or longer.
Then, you can modify the access
function for running jobs by ensuring that only Vercel can invoke your runner.
This works because Vercel automatically makes the CRON_SECRET
environment variable available to the endpoint as the Authorization
header when triggered by the Vercel Cron, ensuring that the jobs can be run securely.
After the project is deployed to Vercel, the Vercel Cron job will automatically trigger the /api/payload-jobs/run
endpoint in the specified schedule, running the queued jobs in the background.
Local API
If you want to process jobs programmatically from your server-side code, you can use the Local API:
Run all jobs:
Run a single job:
Bin script
Finally, you can process jobs via the bin script that comes with Payload out of the box.
In addition, the bin script allows you to pass a --cron
flag to the jobs:run
command to run the jobs on a scheduled, cron basis:
Processing Order
By default, jobs are processed first in, first out (FIFO). This means that the first job added to the queue will be the first one processed. However, you can also configure the order in which jobs are processed.
Jobs Configuration
You can configure the order in which jobs are processed in the jobs configuration by passing the processingOrder
property. This mimics the Payload sort property that's used for functionality such as payload.find()
.
You can also set this on a queue-by-queue basis:
If you need even more control over the processing order, you can pass a function that returns the processing order - this function will be called every time a queue starts processing jobs.
Local API
You can configure the order in which jobs are processed in the payload.jobs.queue
method by passing the processingOrder
property.