{"id":18143,"date":"2026-07-13T13:23:05","date_gmt":"2026-07-13T06:23:05","guid":{"rendered":"https:\/\/www.cipher.co.th\/blogs\/cloudflare-queues-pipelines-email-workers-2\/"},"modified":"2026-07-13T13:23:05","modified_gmt":"2026-07-13T06:23:05","slug":"cloudflare-queues-pipelines-email-workers","status":"publish","type":"post","link":"https:\/\/www.cipher.co.th\/en\/blogs\/cloudflare-queues-pipelines-email-workers\/","title":{"rendered":"Messaging and Data Pipelines on Cloudflare: Queues, Pipelines and Email Workers"},"content":{"rendered":"

Quick answer:<\/strong> Use Queues when you need to move work off the request path and retry it reliably; it bills per operation, not per byte. Use Pipelines when you need to ingest high-volume events, reshape them with SQL, and land them in R2 as Iceberg tables or Parquet files. Use Email Workers when an inbound email is the trigger for your business logic. None of these is Kafka: if you need a replayable event log, multiple independent consumer groups, or more than a few thousand messages per second per queue, Cloudflare is not the answer (pricing as of July 2026).<\/p>\n

Most of the interesting work in a modern backend does not happen inside the request. It happens after: the order is confirmed, the invoice is generated, the webhook is fanned out, the analytics event is written. Cloudflare has three primitives for that layer, and they solve genuinely different problems despite sitting next to each other in the dashboard.<\/p>\n

This article is not a tour of the docs. The docs already tell you what each product does. What is harder to find is a clear statement of which primitive fits which shape of problem, what it actually costs at realistic volume, and where you should walk away from Cloudflare and pick up Kafka or SQS instead. Every number below comes from Cloudflare’s own pricing and limits pages as of 13 July 2026.<\/p>\n

One piece of context first, because it changes how you reason about all of this: Workers bill CPU time, not wall-clock time. A Worker sitting idle waiting on a slow upstream API is not accumulating charges. This is why a fan-out pipeline that calls a dozen APIs is often much cheaper on Cloudflare than people expect. We covered the mechanics in Cloudflare Workers vs AWS Lambda<\/a>.<\/p>\n

Cloudflare Queues: a queue that bills per operation<\/h2>\n

Queues is a push-based message queue (pull consumers are also available) that binds directly into a Worker. Your producer Worker writes messages; a separate consumer Worker receives them in batches, with retries and a Dead Letter Queue built in. There is no broker to provision, no partition count to guess, and no cluster to patch.<\/p>\n

How billing actually works, and where people get it wrong<\/h3>\n

Queues does not charge per message. It charges per operation<\/em>, where one operation is every 64 KB of data written, read, or deleted. In the normal case, delivering one message costs three operations: one write, one read, one delete.<\/p>\n

The subtlety that catches teams out is the 64 KB chunking. A 127 KB message counts as two chunks, so it costs twice as much to write, read and delete as a small message. Every retry also incurs another read per message<\/em>, not per batch: a batch of 10 messages that gets retried once costs 10 additional read operations, not one. If your consumer is flaky, your Queues bill is not linear in message count \u2014 it is linear in message count multiplied by your failure rate.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Dimension<\/th>\nWorkers Free<\/th>\nWorkers Paid<\/th>\n<\/tr>\n<\/thead>\n
Standard operations<\/td>\n10,000 operations\/day included<\/td>\n1,000,000 operations\/month included, then $0.40\/million<\/td>\n<\/tr>\n
Message retention<\/td>\n24 hours (not configurable)<\/td>\n4 days default, configurable up to 14 days<\/td>\n<\/tr>\n
Maximum message size<\/td>\n128 KB<\/td>\n<\/tr>\n
Per-queue throughput<\/td>\n5,000 messages\/second<\/td>\n<\/tr>\n
Per-queue backlog<\/td>\n25 GB<\/td>\n<\/tr>\n
Maximum consumer batch size<\/td>\n100 messages<\/td>\n<\/tr>\n
Concurrent consumer invocations<\/td>\n250 (push-based)<\/td>\n<\/tr>\n
Consumer duration (wall clock)<\/td>\n15 minutes<\/td>\n<\/tr>\n
Message retries<\/td>\n100<\/td>\n<\/tr>\n
Egress \/ bandwidth charges<\/td>\nNone<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The 15-minute limit is the constraint that will bite you<\/h3>\n

A queue consumer invocation has a hard wall-clock limit of 15 minutes. This is the same ceiling that applies to Cron Triggers and to Durable Object alarm handlers. Note that this is wall-clock, not CPU: it counts the time you spend waiting on network calls too.<\/p>\n

If a single unit of work in your system can plausibly take longer than 15 minutes \u2014 a large transcode, a paginated sync against a slow third-party API, a batch export \u2014 you cannot finish it inside one consumer invocation. Your options are to decompose the work into smaller messages that re-enqueue themselves, or to stop using Queues for that job and use Workflows, where an individual step has no wall-time limit.<\/p>\n

CPU time is a separate budget: the default is 30 seconds per consumer invocation, and it can be raised to 5 minutes on Workers Paid by setting limits.cpu_ms in your Wrangler configuration.<\/p>\n

Use Queues when \/ do not use Queues when<\/h3>\n

Use it when:<\/strong> you want to return a response to the user immediately and do the real work behind it; the work needs automatic retries; you want a Dead Letter Queue without operating one. Classic fits are post-checkout order processing, sending confirmation emails, generating thumbnails from a freshly uploaded file, and webhook fan-out to downstream systems.<\/p>\n

Do not use it when:<\/strong> you need to replay events after they have been consumed \u2014 Queues deletes a message once it is acknowledged, and retention caps at 14 days regardless; you need more than 5,000 messages per second into a single queue; you need several independent consumer groups reading the same stream at their own pace (the Kafka consumer-group model); or your messages are meaningfully larger than 64 KB, in which case you should store the payload in R2 and put only the key on the queue.<\/p>\n

Cloudflare Pipelines: ingest, transform with SQL, land in R2<\/h2>\n

Pipelines looks superficially like Queues and is a completely different tool. It is not built to run business logic per message. It is built to absorb a high volume of events, reshape them with SQL at ingestion time, and write them to R2 either as Apache Iceberg tables (via R2 Data Catalog) or as Parquet and JSON files.<\/p>\n

The three moving parts are streams (durable buffers that accept events over an HTTP endpoint or a Worker binding), pipelines (the SQL transformation), and sinks (the R2 destination). Cloudflare states that delivery to sinks is exactly-once, which matters a great deal if you are building anything that gets reconciled against finance.<\/p>\n

Pricing and limits during open beta<\/h3>\n

Pipelines is in open beta and available to any account on a Workers Paid plan. Cloudflare is not currently billing for Pipelines itself. You pay only standard R2 storage and operation charges for the data your sinks write. Cloudflare has said it plans to bill on volume of data processed, transformed and delivered, with at least 30 days’ notice before anything changes.<\/p>\n

The beta limits are narrow and you should design against them before you commit: a maximum of 20 streams per account, 20 sinks per account, 20 pipelines per account, a 5 MB maximum payload per ingestion request, and a maximum ingest rate of 5 MB\/s per stream.<\/p>\n

Use Pipelines when \/ do not use Pipelines when<\/h3>\n

Use it when:<\/strong> you have clickstream data, server logs, IoT telemetry or mobile app events that should end up in a data lake for later analysis, and you do not want to run Kafka Connect or Flink to get them there. The real payoff is on the far side: R2 charges nothing for egress, so the data you park in the lake can be queried by an external engine without a bandwidth bill. We laid out that argument in detail in Cloudflare R2 vs S3<\/a>.<\/p>\n

Do not use it when:<\/strong> you need sub-second latency from producer to consumer \u2014 Pipelines batches into object storage; it is not a message bus. Do not use it when you need to ingest faster than 5 MB\/s on a single stream, or when another system needs to subscribe to the events in real time. Both of those are queue or log problems, not lake problems.<\/p>\n

And because Pipelines is still beta with unannounced pricing, putting it on the critical path of a system where cost predictability matters is a real business risk. That is worth raising with your team before you build.<\/p>\n

Email Workers: email as a trigger<\/h2>\n

What used to be called Email Routing now sits inside a product called Email Service, which covers both inbound routing and outbound sending. The mechanism is unchanged: point your domain’s MX records at Cloudflare, then write a Worker with an email handler. That handler receives the message as an object you can inspect for headers, parse as MIME, forward, reject, or hand off to a Queue.<\/p>\n

Pricing and limits<\/h3>\n
\n\n\n\n\n\n\n\n\n\n\n
Dimension<\/th>\nFree<\/th>\nPaid<\/th>\n<\/tr>\n<\/thead>\n
Inbound emails (Email Routing)<\/td>\nUnlimited<\/td>\nUnlimited<\/td>\n<\/tr>\n
Outbound emails (Email Sending)<\/td>\nOnly to account-owned verified addresses<\/td>\n$0.35 per 1,000 emails<\/td>\n<\/tr>\n
Total message size<\/td>\n25 MiB including attachments<\/td>\n<\/tr>\n
Recipients per email (to + cc + bcc)<\/td>\n50<\/td>\n<\/tr>\n
Routing rules \/ destination addresses<\/td>\n200 \/ 200<\/td>\n<\/tr>\n
The Worker itself<\/td>\nBilled as standard Workers usage<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The caveat that matters most: the Worker processing the email is still a Worker, which means 128 MB of memory per isolate, a ceiling that cannot be raised on either plan. Trying to parse a 20 MB email with several large attachments inside a single Worker invocation is a good way to hit that memory limit. The safer pattern is to have the email handler do as little as possible \u2014 write the raw message to R2, put the object key on a Queue, and let a consumer with a higher CPU budget do the MIME parsing and the model calls.<\/p>\n

Use Email Workers when \/ do not use Email Workers when<\/h3>\n

Use it when:<\/strong> an inbound email is the trigger for business logic. Support systems that open a ticket from an email, systems that receive purchase orders from suppliers as email attachments, bounce-notification parsers, custom spam filters using your own rules. Also use it when you need to send a modest volume of transactional email \u2014 magic links, confirmations \u2014 and do not want to run an SMTP relay.<\/p>\n

Do not use it when:<\/strong> you are doing marketing email or newsletters that need a template editor, list segmentation, A\/B testing, full unsubscribe management and deliverability reporting. SendGrid, Postmark or Amazon SES will do that job far better. Cloudflare has positioned Email Service as a developer primitive, not a full ESP, and it is honest about that.<\/p>\n

Workflows: when 15 minutes is not enough<\/h2>\n

If your job is a long-running sequence with state, and some steps need to wait hours or days, Queues is the wrong answer and Workflows is the right one. Individual Workflow steps have no wall-time limit (they are still subject to the configured CPU limit), and a step that is sleeping accrues no CPU time at all.<\/p>\n

Today Workflows bills exactly like Workers on three dimensions \u2014 requests, CPU time and storage. Workers Paid includes 10 million requests and 30 million CPU-milliseconds per month, plus 1 GB of storage, then $0.20 per GB-month.<\/p>\n

What is about to change:<\/strong> per the changelog of 7 July 2026, Cloudflare has announced that Workflows is moving to per-step billing, starting no earlier than 10 August 2026. Paid will include 500,000 steps per month, then $0.80 per additional 100,000 steps; Free will get 3,000 steps per day. If you are designing a workflow with a large number of small steps, that dimension belongs in your cost model now, not after the first invoice.<\/p>\n

Worked example: an order-processing queue at 2M messages\/month<\/h2>\n

Take a mid-sized Thai e-commerce platform processing 2 million order events a month. Each message is well under 64 KB (an order ID plus a little metadata). The consumer processes them in batches of 10.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Line item<\/th>\nCalculation<\/th>\nMonthly cost<\/th>\n<\/tr>\n<\/thead>\n
Workers Paid<\/td>\nBase subscription<\/td>\n$5.00<\/td>\n<\/tr>\n
Queues operations<\/td>\n2,000,000 x 3 = 6,000,000 ops; minus 1,000,000 included = 5,000,000 x $0.40\/million<\/td>\n$2.00<\/td>\n<\/tr>\n
Retries at 5% (one retry each)<\/td>\n100,000 additional read ops x $0.40\/million<\/td>\n$0.04<\/td>\n<\/tr>\n
Worker requests<\/td>\n2,000,000 \/ 10 = 200,000 invocations (within the 10M included)<\/td>\n$0.00<\/td>\n<\/tr>\n
CPU time<\/td>\nAssume 50 ms CPU per invocation = 10M CPU-ms (within the 30M included)<\/td>\n$0.00<\/td>\n<\/tr>\n
Total<\/strong><\/td>\n<\/td>\n~$7.04<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The instructive part is that the queue itself costs two dollars. The rest is the Workers Paid subscription you were already paying for. Doubling the message volume adds roughly $2.40, not another $7, because the $5 is a fixed floor. Conversely, if your messages grow to 100 KB each, the operation count doubles and so does the Queues line \u2014 which is the whole argument for keeping large payloads in R2 and putting only a key on the queue.<\/p>\n

Worked example: a support-ticket triage pipeline from email<\/h2>\n

Now take a Thai SaaS business receiving 30,000 support emails a month. Each one must be parsed, classified, turned into a ticket, and answered with an automated acknowledgement.<\/p>\n

Inbound email costs nothing: Email Routing is unlimited on both Free and Paid. The Email Worker handling 30,000 invocations a month sits comfortably inside the 10 million requests included with Workers Paid. The only real variable cost is the 30,000 outbound acknowledgements, at $0.35 per 1,000 emails, which comes to $10.50 per month.<\/p>\n

The whole system therefore lands at roughly $15.50\/month (Workers Paid $5.00 plus $10.50 of email sending), before you add any AI classification \u2014 which is where Workers AI would come in, and which we cost out separately.<\/p>\n

One practical caution: emails with large attachments will eat the Worker’s 128 MB memory budget quickly. Keep the email handler thin. Write the raw message to R2, put the object key on a Queue, and do the heavy MIME parsing and model calls in a consumer that has a higher CPU ceiling.<\/p>\n

Decision matrix: if you need X, use Y<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n
If you need<\/th>\nUse<\/th>\nWhy<\/th>\n<\/tr>\n<\/thead>\n
To move work off the request path with automatic retries<\/td>\nQueues<\/td>\nRetries, DLQ and batching are built in; billed per operation<\/td>\n<\/tr>\n
Jobs longer than 15 minutes, or steps that wait for days<\/td>\nWorkflows<\/td>\nNo wall-time limit per step; sleeping steps accrue no CPU<\/td>\n<\/tr>\n
To land millions of events in a data lake for later query<\/td>\nPipelines + R2<\/td>\nSQL transform at ingest; Iceberg\/Parquet output; zero egress<\/td>\n<\/tr>\n
Inbound email as a trigger for business logic<\/td>\nEmail Workers<\/td>\nInbound routing is unlimited and free<\/td>\n<\/tr>\n
Modest transactional outbound email<\/td>\nEmail Sending<\/td>\n$0.35 per 1,000 emails; no SMTP relay to run<\/td>\n<\/tr>\n
Scheduled work (nightly jobs, rollups)<\/td>\nCron Triggers<\/td>\nSame 15-minute wall-time ceiling as queue consumers<\/td>\n<\/tr>\n
Per-key coordination such as locks or counters<\/td>\nDurable Objects<\/td>\nOne authoritative instance per key owns the state<\/td>\n<\/tr>\n
To replay an event stream, or many independent consumer groups<\/td>\nKafka (not Cloudflare)<\/td>\nQueues deletes messages on ack; 14-day maximum retention<\/td>\n<\/tr>\n
More than 5,000 messages\/second into one queue<\/td>\nKafka or Kinesis<\/td>\nThat is the hard per-queue throughput limit on Queues<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

When Kafka, SQS or a dedicated tool wins<\/h2>\n

This is the section most vendor content skips. Skip it and you cannot make a real decision.<\/p>\n

Kafka wins when you need a log, not a queue<\/h3>\n

The structural difference is that Kafka stores events as an append-only log where each consumer group tracks its own offset. You can read the same events twice. You can rewind. You can add a brand-new consumer six months later and have it process the entire history from the beginning. Cloudflare Queues does not work this way: a message is deleted once it is acknowledged, and maximum retention is 14 days. If your architecture leans on event sourcing or CQRS and needs to rebuild state from the log, Queues simply cannot answer the question.<\/p>\n

Very high throughput<\/h3>\n

5,000 messages per second per queue is a lot for most businesses. But if you are building ad tech, a trading system, or fleet-scale telemetry that fires tens of thousands of events per second, you will hit that wall. Sharding across multiple queues to work around it means writing your own routing logic \u2014 technical debt you did not need to take on.<\/p>\n

SQS wins when your system already lives in AWS<\/h3>\n

If the rest of your workload runs on AWS and the queue needs to talk to Lambda, Step Functions, EventBridge and IAM policies that already exist, bolting Cloudflare Queues on adds a cross-cloud hop and an AWS egress charge on every message that crosses the boundary. The added cost and latency will usually swallow whatever you saved on the queue itself.<\/p>\n

A data lake you already run<\/h3>\n

Pipelines is still in open beta with tight limits (20 streams per account, 5 MB\/s per stream) and unannounced pricing. If you already run Flink, Spark Streaming or a dbt pipeline and your team knows it well, moving to Pipelines today trades a known quantity for a cheaper, simpler, less capable one that may not be cheaper forever. Start with a non-critical use case.<\/p>\n

For the general runtime constraints that apply across all of this, see when not to use Cloudflare Workers<\/a>, and for the wider storage picture, Cloudflare storage services explained<\/a>.<\/p>\n

Summary for the person who has to decide<\/h2>\n

Three questions get you most of the way there. Does a single unit of work finish inside 15 minutes? If not, use Workflows, not Queues. Do you need to replay events later? If yes, you need Kafka, not Queues. Are your messages larger than 64 KB? If yes, store the payload in R2 and enqueue only the key, because operation costs multiply otherwise.<\/p>\n

Cipher designs and implements systems on the Cloudflare Developer Platform for businesses in Thailand. If you are weighing Queues, Workflows or keeping the message broker you already run, we can assess the architecture and help you cost out the realistic options against your actual volume.<\/p>\n

Frequently Asked Questions<\/h2>\n

How is Cloudflare Queues different from Kafka<\/h3>\n

Queues is a queue, not a log. A message is deleted once the consumer acknowledges it, and maximum retention is 14 days on Workers Paid. Kafka stores events as an append-only log that multiple consumer groups can read independently and rewind, so if you need event sourcing or replay, Queues cannot answer that requirement.<\/p>\n

What is the maximum runtime for a queue consumer<\/h3>\n

Fifteen minutes of wall-clock time per invocation, which is the same ceiling as Cron Triggers and Durable Object alarm handlers. CPU time is a separate budget with a default of 30 seconds, and it can be raised to 5 minutes on Workers Paid by setting limits.cpu_ms.<\/p>\n

How does Cloudflare Pipelines bill right now<\/h3>\n

Pipelines is in open beta and Cloudflare is not currently charging for the product itself. You pay only standard R2 storage and operation charges for data that sinks write into R2. Cloudflare has committed to at least 30 days of notice before it starts billing (information as of July 2026).<\/p>\n

Can Email Workers send outbound email, and what does it cost<\/h3>\n

Yes, via the send_email binding in Email Service. Inbound email routing is unlimited and free on both Free and Paid plans. Outbound sending on a Paid plan costs $0.35 per 1,000 emails, while the Free plan can only send to verified addresses that your account already owns.<\/p>\n

What should I use if a job takes longer than 15 minutes<\/h3>\n

Use Workflows, because individual steps have no wall-time limit and a sleeping step accrues no CPU time. Be aware that per the changelog of 7 July 2026, Cloudflare has announced that Workflows will move to per-step billing no earlier than 10 August 2026, with Paid including 500,000 steps per month and $0.80 per additional 100,000 steps.<\/p>\n","protected":false},"excerpt":{"rendered":"

Quick answer: Use Queues when you need to move work off the request path and retry it reliably; it bills […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_angie_page":false,"content-type":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"page_builder":"","footnotes":""},"categories":[152],"tags":[],"class_list":["post-18143","post","type-post","status-publish","format-standard","hentry","category-technology-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts\/18143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/comments?post=18143"}],"version-history":[{"count":0,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts\/18143\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/media?parent=18143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/categories?post=18143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/tags?post=18143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}