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 because they run too many Workflows. They blow it because they don’t know what an “Action” is, can’t map Actions to real traffic, and guess. You can do better than guessing.
Quick Answer: Temporal Cloud pricing is based primarily on Actions (durable operations the Service performs on your behalf). To estimate monthly cost, you approximate Actions per Workflow (and per Activity), multiply by your expected Workflow volume, and then apply the current Actions pricing from the Temporal Cloud pricing page.
Quick Answer: Temporal Cloud costs are driven by how often the Temporal Service does work for you—persisting events, scheduling tasks, firing timers, and handling signals—not by CPU hours or pods. Estimate those operations from your business traffic, then back into Actions.
Frequently Asked Questions
What exactly is an “Action” in Temporal Cloud pricing?
Short Answer: An Action is a billable, durable operation performed by the Temporal Cloud Service—such as recording a Workflow event, scheduling/dispatching an Activity task, firing a timer, or handling a signal/query.
Expanded Explanation:
Temporal Cloud does not charge you for Worker CPU, pods, or “Workflow definitions.” It charges for the concrete, persistent operations the Temporal Service must perform to make your Workflows durable and recoverable. Every time the Service appends an event to a Workflow history, dispatches a task from a task queue, fires a timer, or processes a signal, that’s an Action.
You can think of Actions as “durable execution steps” on the Service side. Your Workers run in your environment; they execute your code. Temporal Cloud coordinates that execution and persists the history. That coordination and persistence is what Actions measure. The result: you only pay for actual usage—no over-provisioned hardware, no oversized databases, and no idle clusters.
Key Takeaways:
- Actions are Service-side operations that make your Workflow execution durable.
- You’re not charged for Worker compute; you’re charged for how much durable coordination you ask Temporal Cloud to perform.
How do I estimate Actions and monthly cost from my expected workflow volume?
Short Answer: Model a “typical” Workflow, count its major steps (Activities, timers, signals), convert that into an approximate Actions-per-Workflow number, multiply by your projected executions per month, and apply the per‑Action rate from the Temporal Cloud pricing page.
Expanded Explanation:
You don’t need a perfect simulation to get a solid cost estimate. You need a reasonable model: how many Workflows will you execute per month, and how “chatty” is each Workflow with the Temporal Service? A Workflow that runs a single Activity and completes will use far fewer Actions than a long‑running Workflow that waits for multiple user signals over weeks with many retries and timers.
Start by picking 2–3 representative Workflow types: for example, “order fulfillment,” “money movement,” and “AI pipeline.” For each, sketch its main steps: how many Activities, how many retries you expect, how many timers, how many signals/queries. Use that to estimate Actions per Workflow, then multiply by your expected monthly volume. Combine that with any free tier credits or contracted discounts.
Steps:
- Identify traffic: Estimate monthly executions for your main Workflow types (e.g., 1M orders, 200k payouts, 50k AI training runs).
- Estimate Actions per Workflow: For each Workflow type, count Activities, expected retries, timers, and signals to approximate Actions per execution.
- Multiply and price: Sum total Actions across Workflow types, then multiply by the per‑Action price listed on the Temporal Cloud pricing page to get a monthly estimate.
How do different workflow designs change Actions (and cost)?
Short Answer: Highly granular Workflows (many short Activities, timers, and signals) consume more Actions but give you more control and visibility; coarser Workflows (fewer, longer Activities) use fewer Actions but push more complexity into your code.
Expanded Explanation:
With Temporal, you choose how much logic you model as discrete Activities, timers, and signals. Every one of those primitives generates Actions. If you split a process into many small Activities with retries and intermediate timers, you pay in Actions but gain precise recovery points, better observability, and easier reasoning about failures. If you collapse that process into one long Activity, you reduce Actions but lose that fine‑grained durability and visibility.
The right answer is rarely “minimize Actions at all costs.” Remember: your alternative cost is manual state machines, custom retry logic, and on‑call firefights. Most teams find that paying for more Actions is cheaper than paying engineers to debug lost state in production.
Comparison Snapshot:
- Fine‑grained Workflows: Many Activities, timers, signals. Higher Actions count. Maximum durability, replay granularity, and observability.
- Coarse‑grained Workflows: Fewer, longer Activities. Lower Actions count. Less granular recovery and reduced visibility into internal steps.
- Best for: Most production systems: use moderate granularity—enough Activities and timers to match real business steps, not every line of code.
How do I practically implement an estimate before I migrate or go to production?
Short Answer: Start with a paper model, then validate it with a small Temporal Cloud namespace running realistic load tests; use observed Actions from the Web UI and billing dashboard to refine your estimate.
Expanded Explanation:
You don’t need to be perfect on day one. Temporal Cloud is built for consumption-based costs, scaling into hundreds of thousands of Actions per second without you managing infrastructure. Start with a simple spreadsheet model. Then stand up a Temporal Cloud namespace, run a realistic test load (e.g., 1–5% of expected production volume), and measure actual Actions.
You can inspect execution histories and metrics in the Temporal Web UI, then correlate that with billing data. This loop lets you tune your design—e.g., combine Activities that are too fine‑grained, or add timers where visibility is worth the extra Actions. Because Workers run in your own environment and we never see your code, you can safely iterate on your design while Temporal Cloud handles Service-side scale, durability, and availability.
What You Need:
- A draft volume model for your core Workflows (types, monthly counts, rough step counts).
- Access to a Temporal Cloud namespace and its billing/usage metrics to calibrate your estimates with real traffic.
How should we think about cost strategically as we scale Temporal Cloud across teams?
Short Answer: Treat Actions as a shared reliability budget: invest them where durability, visibility, and recoverability matter most, and centralize patterns so teams reuse proven Workflow designs instead of reinventing state machines.
Expanded Explanation:
When you adopt Temporal Cloud broadly, cost should track business value, not infrastructure guesswork. You’re moving from paying for idle capacity and over-provisioned databases to paying for real, completed work. Every Action represents a durable step toward a business outcome: an order shipped, a payment reconciled, an AI job completed.
Strategically, you want to standardize on a few Workflow patterns—order pipelines, money movement, CI/CD rollbacks, AI pipelines—and let teams reuse them as libraries. That concentrates Actions in critical paths where the cost of failure is high and manual recovery is expensive. You also get predictable economics: if you know an order costs ~X Actions, then cost scales linearly with order volume, not with the number of microservices or cron jobs you’ve deployed.
Why It Matters:
- Cost tracks value: You pay for durable progress toward real business events (Workflows completing), not for idle servers or over-sized clusters.
- Less toil, fewer incidents: More Actions often means more durable checkpoints and better visibility—reducing manual recovery work and on‑call stress.
Quick Recap
To estimate your monthly Temporal Cloud cost, don’t start with servers or pods—start with Workflows and Actions. Model typical Workflows, estimate how many Activities, retries, timers, and signals they use, convert that into Actions per execution, and multiply by your projected monthly volume. Then validate with a small Temporal Cloud namespace and real traffic, adjusting your Workflow granularity where it meaningfully reduces Actions without sacrificing durability and visibility. In the end, you trade undifferentiated infrastructure and brittle state machines for a predictable, usage-based cost model tied directly to durable business outcomes.