The clock your serverless Payload app doesn’t have.
Nothing runs between requests on serverless, so queued jobs wait. Payload Clock calls your job queue on schedule, drains the backlog in one pass, keeps a history worth reading, and tells you the moment it stops.
An independent project built for the Payload community — not affiliated with or endorsed by Payload CMS.
The gap
Payload has a job queue. Serverless has no hand to turn it.
The queue, the tasks, the workflows and the schedules are all already there and all work exactly as documented. The one missing piece is something outside the deployment that calls it.
- Nothing runs between requests.
- Payload’s autoRun needs a process that stays alive. On Vercel, Netlify, Cloudflare and every other serverless target there isn’t one, so queued tasks and scheduled workflows sit untouched until somebody happens to load a page.
- Platform cron is rationed.
- Vercel’s Hobby plan allows two cron jobs at a daily minimum. That is a nightly batch, not a job queue — and it is the wall most Payload projects hit first.
- One call is not a drain.
- A single request to the run endpoint processes up to its limit and returns. If four hundred jobs arrive at once, a plain cron leaves most of them for tomorrow and the backlog never clears.
- A cron that stops is silent.
- Nothing tells you the schedule stopped firing. You find out when a customer asks why their email never arrived, which is the worst possible monitoring system.
How it works
One tick. One batch. Every project.
Point Clock at your deployment
A URL and a secret. Clock proves you own the endpoint before it ever calls it — one click if you install the plugin, a DNS record if you would rather not.
Pick a cadence
Every five minutes by default. An interval from one minute to a day, or a cron expression with a time zone. One monitor per project is the whole setup for almost everyone: Payload’s own scheduler decides which jobs are due, Clock only has to knock.
Clock calls, and keeps calling until the queue is empty
Payload answers every call with how much work is left. When there is more, Clock goes straight round again rather than waiting for the next minute — so a four hundred job backlog clears in one pass instead of over an afternoon.
You get told when it breaks
Three failures in a row and you get an email naming the status code. Twenty and the monitor pauses itself, because at that point the deployment is gone and pinging it is noise.
The minute’s work leaves as one batch rather than as one request per project. That is the whole reason this can be free: the bill is per batch, and a batch costs the same carrying fifty projects as carrying one.
What you get
A trigger is easy. The six things around it are the product.
Anything can send an HTTP request on a timer. What makes a job queue trustworthy is what happens on the calls that go wrong, and on the ten thousand that go right and say nothing.
- It drains, it doesn’t just knock.
- Payload returns how many jobs are left. Clock reads that and calls again in the same pass, up to five times, stopping the moment the queue is clear or the backlog stops shrinking.
- History you can actually read.
- Eleven thousand identical “nothing to do” runs collapse into one row with a count and a duration range. Failures never collapse. What is left on screen is only the part that changed.
- Signed requests, no shared secret on the wire.
- With the plugin installed, Clock sends a timestamped HMAC instead of a bearer token. Your secret never leaves your deployment, and a captured request is worthless five minutes later.
- It knows when to stop.
- Three consecutive failures send an email; twenty pause the monitor. Abandoned deployments cost you nothing and cost us nothing, which is the same sentence.
- Per-queue when you need it.
- Give a heavy queue its own cadence and its own job limit, and let one monitor carry Payload’s schedule handling for the rest.
- Nothing of yours is stored.
- Clock calls one URL and records a status code, a duration and an error string capped at two hundred characters. It never sees a job payload, and there is nowhere for one to land.
| Fri 17:02 | Ran200 · 3 jobs, queue drained | 200 | 3 jobs, queue drained | 412 ms |
| Fri 16:58 | Failed500 · ECONNRESET | 500 | ECONNRESET | 20.0 s |
| Fri 16:57 | Failed502 · Bad Gateway | 502 | Bad Gateway | 1.2 s |
| Tue 09:14 — Fri 16:56 | Nothing to do200 · 11,208 runs | 200 | 11,208 runs | 40–95 ms |
| Tue 09:13 | Ran200 · 41 jobs, 2 drain calls | 200 | 41 jobs, 2 drain calls | 2.8 s |
One monitor, one week. The middle row is eleven thousand runs in which nothing happened, folded into a single line — and the two rows above it are the ninety seconds that mattered.
Wherever you deploy
One clock, every region.
Payload Clock runs in one place and calls yours wherever it is — iad1, fra1, syd1, a container in your own cloud. A job-queue ping is not latency-sensitive: what matters is that it arrives, that it is retried when it doesn’t, and that you hear about it either way.
Connect
Two lines in your Payload config.
Payload’s run endpoint is closed to everyone but a logged-in user until you say otherwise, so connecting Clock means telling Payload to trust it. The plugin ships that access function, verifies your deployment in one click, and puts the next and last ten runs inside your admin.
import { clockPlugin, clockAccess } from '@payload-solutions/plugin-clock'
export default buildConfig({
plugins: [clockPlugin({ projectToken: process.env.PAYLOAD_CLOCK_TOKEN })],
jobs: {
// Clock signs every request; the plugin checks the signature.
access: { run: clockAccess() },
},
})export default buildConfig({
jobs: {
access: {
run: ({ req }) =>
req.headers.get('authorization') === `Bearer ${process.env.CLOCK_SECRET}`,
},
},
})Free
Free, and here is the arithmetic.
A free tier nobody can afford gets withdrawn, so it is worth showing the working. Payload Clock sends one batch a minute for every customer at once, and the metered service behind it bills per batch, not per ping. A million operations a month are free; a minute of batches costs two. That leaves room for thousands of monitors inside a free allowance — and past it, a million more operations costs forty cents.
- Projects
- 5
- Monitors
- 10
- Shortest interval
- 1 minute
- Run history
- 7 days, 30 on failure
- Failure alerts
- email and webhook
- Price
- none
Limits for the free plan at launch, and they may move before it opens. A paid plan, if one arrives, will buy longer retention and more projects — never the right to be called on time.