Durable Workflow Orchestration
How do I estimate our monthly Temporal Cloud cost from expected workflow volume and Actions?
7 min read
Most teams don’t blow their Temporal Cloud budget—they just don’t know how to estimate it. The good news is that Temporal pricing is linear, usage-based, and mapped to a single unit: Actions. If you can roughly model your Workflow and Activity volume, you can get within striking distance of your monthly bill before you ever run in production.
Quick Answer: Temporal Cloud cost is driven primarily by Actions. To estimate your monthly cost, approximate how many Workflow executions you’ll run per month, how many Activities and state transitions each will perform, convert that to Actions, and apply the current per‑Action rate from the pricing page—then add any support or premium features you choose.
Frequently Asked Questions
How do Actions map to my Workflow and Activity volume?
Short Answer: Actions are the fundamental billing unit in Temporal Cloud; they roughly correspond to state transitions in your Workflow execution histories (starting Workflows, scheduling Activities, completing Activities, timers, signals, etc.).
Expanded Explanation:
Temporal Cloud doesn’t charge per server, cluster, or “Workflow definition.” It charges for the work the Temporal Service actually does to drive your code to completion. Every meaningful piece of work—starting a Workflow, scheduling an Activity, recording a completion, firing a timer, processing a signal or query—shows up as events in the Workflow’s event history. Those events are aggregated and exposed as Actions for billing.
In practice, you can think of an Action as “a single step in the durable state machine that Temporal maintains for you.” If you have a Workflow that runs a handful of Activities, sets a couple of timers, and receives a signal or two, that will translate into tens to low hundreds of Actions, not thousands. This is why cost estimation starts with modeling your processes as code and then counting how many steps they execute per run.
Key Takeaways:
- Actions are tied to execution history events: Workflow starts, Activity scheduling/completion, timers, signals, and similar transitions.
- Cost scales with how much real work Temporal performs on your behalf, not with cluster size or number of Workflow definitions.
How do I estimate Actions per month from my expected workload?
Short Answer: Model a typical Workflow, count its Activities and other key steps, turn that into approximate Actions per execution, then multiply by your expected monthly Workflow volume.
Expanded Explanation:
To estimate Actions, you don’t need an exact event breakdown. You need a reasonable model of your business flows. Start with one representative Workflow type—say, order fulfillment, money movement, or an AI pipeline—then count how many Activities, timers, and signals it uses in a normal execution. Each Activity involves multiple Actions (schedule, start, completion, possible retries). Timers, signals, and child Workflows each contribute additional Actions.
Once you have an Actions‑per‑Workflow estimate, multiply by how many times that Workflow will run per month. Repeat for other high‑volume Workflow types and sum them. Temporal pricing is linear, so if your estimates are off by 20–30%, your cost estimate will be off by about the same percentage—easy to refine as you collect real telemetry.
Steps:
-
Pick representative Workflow types
Identify your highest‑volume or most expensive flows (e.g., payments, order processing, user provisioning, CI/CD, AI training runs). -
Estimate Actions per execution
- Count Activities per Workflow (including likely retries).
- Add timers, signals, and child Workflows.
- Multiply Activities by a small constant (e.g., 5–10 Actions per Activity as a first‑pass) and add a few Actions per timer/signal.
-
Multiply and sum
- Actions per execution × executions per month = monthly Actions for that Workflow type.
- Sum across all Workflow types, then apply the per‑Action price from the Temporal Cloud pricing page to estimate monthly cost.
How does Temporal Cloud cost compare to self‑hosting Temporal?
Short Answer: Self‑hosting shifts cost into infrastructure, operations, and on‑call time, while Temporal Cloud charges directly on Actions for a fully managed, globally available Service.
Expanded Explanation:
Without Temporal Cloud, you’re paying for hardware (or cloud instances), databases, storage, observability, and a team to run all of it with high availability. You’re also paying in latency, incidents, and opportunity cost when internal teams are debugging cluster issues instead of shipping features. Temporal Cloud removes the entire control plane burden: no cluster sizing, no database tuning, no complex upgrades. You only pay for Actions, plus any support tier you choose.
Self‑hosting can look cheaper at very low scale if you already have a strong ops team and a mature platform. As volume grows, the headcount and infrastructure required to keep a Temporal cluster robust across regions and failure modes grows as well. Temporal Cloud is designed to scale Actions up and down without you having to over‑provision for spiky workloads.
Comparison Snapshot:
-
Option A: Self‑host Temporal OSS
- You manage clusters, databases, upgrades, backups, and disaster recovery.
- Costs are infra + DB + engineering time (SRE + platform + on‑call).
-
Option B: Temporal Cloud
- Managed, high‑availability Service with built‑in replication, DR, and low‑latency routing.
- You pay per Action and optional support/services; you still own your Worker code and infrastructure.
-
Best for:
- Self‑hosting: teams with strict in‑house infra mandates and the appetite to run distributed systems.
- Temporal Cloud: teams that want to manage Workflows, not infrastructure, and scale without guessing cluster capacity.
What do I need in place to get an accurate Temporal Cloud cost estimate?
Short Answer: You need a rough model of your core Workflows (steps, retries, timeouts), baseline volume assumptions, and the current per‑Action price; optional observability can refine the estimate as you test.
Expanded Explanation:
Temporal pricing is deliberately transparent so you can estimate cost early—long before production traffic. The more you understand your own processes, the more accurate your estimate will be. Start by modeling your primary flows in code using the Temporal SDK of your choice. Even a small proof‑of‑concept on Temporal Cloud can give you real Action counts per execution, which you can then extrapolate to your full expected load.
You don’t need a full migration to get a good estimate. A thin slice of a representative Workflow (e.g., one payment path, one order path, one AI job) is enough to see realistic event histories and Action counts in the Temporal Web UI. From there, it’s just multiplication.
What You Need:
- A catalog of your high‑volume or critical processes and how they’d map to Workflows/Activities.
- Current pricing details from the Temporal Cloud pricing page (per‑Action cost, any committed spend or support tiers you’re considering).
How should we think about Temporal Cloud cost strategically as we scale?
Short Answer: Treat Actions as the unit of reliability: as you move more critical flows onto Temporal, your Action volume becomes a proxy for “work you no longer have to recover manually,” and the cost should be evaluated against reduced outages, fewer orphaned processes, and less custom state management.
Expanded Explanation:
Temporal Cloud flips the usual reliability trade‑off. Instead of paying for more engineers to build state machines, retry wrappers, cron jobs, and runbook‑driven recovery, you pay for Actions that guarantee your code runs to completion despite crashes, timeouts, or flaky networks. Every Action is a recorded step in a Workflow that you can inspect, replay, and rewind from the Web UI.
As your usage grows, you’re not just increasing your bill—you’re reducing the surface area where failures can hurt you. Order fulfillment, money movement, CI/CD rollbacks, long‑running AI pipelines: when all of these are expressed as Workflows with durable state, you spend less time firefighting and more time shipping. The “cost” of additional Actions should be weighed against avoided incidents, reduced operational toil, and faster feature delivery.
Why It Matters:
- More Actions mean more of your mission‑critical logic is protected by Temporal’s durable execution and automatic recovery semantics.
- Cost scales with actual business value delivered—completed operations without lost progress—rather than idle infrastructure or over‑provisioned capacity.
Quick Recap
Estimating your monthly Temporal Cloud cost is a modeling exercise, not a guessing game. Start by describing your key processes as Temporal Workflows, estimate Actions per execution (Activities, timers, signals, child Workflows), and multiply by expected monthly volume. Apply the per‑Action rate and layer in any support or services you need. As you move more flows onto Temporal, remember that cost tracks how much work is no longer vulnerable to partial failure and manual recovery.