Move slow work out of the request.
Your function or app puts a message on a queue and answers at once. A function, an HTTPS address or your own app takes the messages, with retries, a dead-letter queue for what failed, and schedules for recurring work.
What you get
env.JOBS and the API
Send from any function or app with send or sendBatch, or from anywhere with the API, with an optional delay and a deduplication id so a message is not stored twice. A body is any JSON value up to 128 KB.
A function consumer
A function's queue(batch, env) handler gets messages in batches of up to 100. You set the batch size, the wait and the concurrency.
Delivery to a URL
Each message is POSTed to any HTTPS address, signed with the Standard Webhooks headers so the receiver can verify it with any Standard Webhooks library. A 2xx answer acks it.
Pull from outside
An app outside the platform takes messages over HTTPS (pull) and acks them when done; a message not acked is available again after its visibility timeout.
Retries with backoff
A message that was not processed is delivered again, the wait doubling each time, up to the maximum you set for the queue (up to 100).
Dead-letter queue
After the last retry a message moves to the dead-letter queue with the reason. Browse it, send the messages back to their queue, or purge them.
Schedules
A cron expression with a time zone (Tehran by default) sends a message to a queue, a function or a URL each time it fires.
At-least-once delivery
A message is stored durably before send answers, so losing a server does not lose it.
Metrics and peek
Messages ready, in flight and delayed, age of the oldest, send, delivery and failure rates. Look at messages, pause the queue or purge it.
One queue, three ways to consume
A function, an HTTPS address, or your own app with pull. Answering normally acks; an error retries, with backoff.
cloudhost queues create jobs-failed
cloudhost queues create jobs --dead-letter-queue jobs-failed --max-retries 5
cloudhost queues consumer jobs worker --batch-size 10
cloudhost schedules create "0 3 * * *" --queue jobs --body '{"task":"nightly"}'Per operation
Sending, delivering and acking (or retrying) are one operation each, of up to 64 KB; a message that succeeds the first time is three. Hobby has 10,000 operations a day, then refuses until the next day; Pro includes 1,000,000 a month, and more is charged from the wallet per million operations.
Limits
| Hobby | Pro | |
|---|---|---|
| Queues per team | 10 | 10,000 |
| Message size | 128 KB | 128 KB |
| Retention | 1 day | up to 14 days |
| Backlog per queue | 1 GB | 25 GB |
| Delivery delay | up to 1 hour | up to 7 days |
| Schedules | 10 | 1,000 |
| Operations | 10,000 a day, then refused | 1,000,000 a month included, then per use |
Questions
The messages not acked are delivered again after a wait that doubles each time. After the last retry they move to the dead-letter queue, or are dropped and counted if there is none. For a URL, any answer other than 2xx, or no answer within the visibility timeout, is a retry.
Yes, delivery is at least once. Write the consumer so that running twice does no harm.
Each delivery carries the webhook-id, webhook-timestamp and webhook-signature headers, an HMAC with the secret shown once when you set the URL (whsec_). Any Standard Webhooks library verifies it. Rotate the secret whenever you like.
Hobby has 10 queues and 10 schedules, Pro 10,000 queues and 1,000 schedules. The limits table above and the guide have the details.
Create your first queue
One command for the queue, one line to send.
Sign-up is by invite for now. If you have a code, create your account.
Sign up withEmail codeSMS code