Users enter when they subscribe to the purchase-signal list. Before any email is sent, two Y/N splits gate the journey: (1) a suppression list check that ejects anyone in [Main] Suppression List, and (2) a Products News and Promotions eligibility check. Users who pass both gates receive M1 marketing + M2. Users who fail the eligibility check receive a transactional-only M1, then exit — no M2.
6722xwwq. Subscribing to this list is the signal that the user purchased a Workers Paid plan.Users flow top-down from Start into two back-to-back Y/N splits before any email fires. The suppression split ejects anyone in [Main] Suppression List. The eligibility split forks the journey: eligible users get M1 marketing → 5-day delay → M2; ineligible users get a transactional M1 only, then exit.
The full copy for both milestone emails. Each subject line runs an A/B test (Variant A / Variant B); the body is identical across variants. CTAs point developers back into the Workers dashboard.
The paid plan removes the ceilings that block production workloads.
Higher request limits, more CPU time, and access to the full Workers toolset — all on the same account and dashboard you're already using.
| Free | Paid | |
|---|---|---|
| Requests | 100,000 / day | Unlimited (10M/mo included, then $0.30/M) |
| CPU time | 10 ms / request | Up to 5 min / request (default 30 s) |
| Subrequests | 50 / request | 10,000 / request (configurable up to 10M) |
| Worker script size | 3 MB | 10 MB |
| # Workers per account | 100 | 500 |
| Cron Triggers | 5 | 250 |
Cloudflare Workers Explained · Cloudflare Developers
Most developers on the paid plan know they got higher request limits. Fewer know about everything else that came with it.
Here's what came with it that most developers overlook. None of these are available on the free plan:
send_email binding. 3,000 emails per month included, then $0.35 per 1,000.Both emails ran a subject-line A/B test — same body, different subject. The variants and the read on why each performed are captured below to guide future upgrade and onboarding messaging.
In Iterable, A/B tests on journey emails are called Experiments. We run one on both milestone emails — subject lines only. Each optimizes for unique open rate (getting the developer back into the inbox to see what their plan unlocked).
| What's tested | Variant A | Variant B | Win condition | |
|---|---|---|---|---|
| M1 — Welcome | Subject line | "You're on the Workers Paid plan. Here's what it unlocks." | "You just upgraded. Here's everything that came with it." | Unique open rate |
| M2 — Lesser-known features | Subject line | "You unlocked more than higher limits. Here's what most developers miss." | "These paid features are already on your account. Most developers never find them." | Unique open rate |
"You're on the Workers Paid plan. Here's what it unlocks."
Developers respond to explicit, transactional framing. Suggests they want to know what changed on their account, not be sold to. Tells you future upgrade emails should lead with the plan name and a direct value statement.
"You just upgraded. Here's everything that came with it."
Conversational tone outperforms formal tone. Suggests developers respond better to language that acknowledges the action they just took rather than restating the plan name.
"You unlocked more than higher limits. Here's what most developers miss."
The curiosity gap works. "Most developers miss" creates tension on FOMO. Suggests developers are motivated by not wanting to leave value on the table.
"These paid features are already on your account. Most developers never find them."
Ownership framing outperforms the curiosity gap. Makes the value feel immediately accessible. Suggests future onboarding emails introducing the upgrade/purchase should lead with what they already have, not what they might be missing.
Primary metrics measure immediate message performance. Secondary metrics test whether informed users actually engage with — and retain on — the paid plan over time.