Durable Workflow Orchestration
Temporal Cloud pricing: how do Actions, Active Storage, and Retained Storage billing work?
8 min read
Most teams don’t lose money on cloud compute; they lose it on surprises. Temporal Cloud’s pricing is intentionally simple: you pay for the work your system actually does (Actions) and the Workflow history you actually keep (Active and Retained Storage). No capacity planning, no over-provisioned databases, and no “just in case” clusters sitting idle.
Quick Answer: Temporal Cloud bills on three primary usage dimensions: Actions (units of Workflow execution work), Active Storage (Workflow history for open and recently closed executions), and Retained Storage (long-term history retention). You’re charged based on what you use, so cost scales directly with the complexity and volume of your Workflow executions—not with pre-allocated infrastructure.
Frequently Asked Questions
How does Temporal Cloud pricing work overall?
Short Answer: Temporal Cloud uses a consumption-based model where you pay for Actions, Active Storage, and Retained Storage, plus any support or expert services you choose.
Expanded Explanation:
Instead of buying and managing clusters, databases, and storage directly, you pay Temporal Cloud for the actual work your system performs. Every Workflow step—starting a Workflow, scheduling an Activity, tracking heartbeats, firing a timer, recording a signal—is measured in Actions. The event history those Workflows generate is stored as Active Storage while they’re running and for a configurable period after completion. If you choose to keep execution history longer (for debugging, audit, or analytics), that data moves into Retained Storage.
Because pricing is tied to your execution patterns, you can scale up to large volumes or long-running Workflows without having to guess hardware sizes or over-provision databases. Temporal Cloud’s architecture handles high availability, durability, and scaling (into hundreds of thousands of Actions per second) under the hood; you only see it on your bill as more Actions and storage, not as bigger clusters.
Key Takeaways:
- You pay for usage, not pre-allocated capacity.
- Costs track three things: Actions, Active Storage, and Retained Storage, plus optional support/services.
What exactly is an Action in Temporal Cloud billing?
Short Answer: An Action is the fundamental billing unit representing a single Temporal API operation or Workflow state transition, such as starting a Workflow, scheduling an Activity, recording a heartbeat, or firing a timer.
Expanded Explanation:
Think of an Action as “one unit of reliable coordination work” performed by the Temporal Service. When your code asks the Service to do something—start a Workflow, enqueue an Activity task, apply a retry policy after a failure, record a signal from a user—Temporal records an event and advances that Workflow’s state machine. Each of these discrete operations is counted as one or more Actions.
This is deliberate. In distributed systems, failures happen at the edges: APIs fail, networks flake, services crash. Every time Temporal helps your code move safely through those edges—persisting state, rescheduling Activities, processing a timer, or applying a signal—that’s an Action. Instead of you provisioning databases and building state machines to track this state, Temporal does it for you, and you pay proportionally to how much coordination you need.
You don’t need to count Actions manually in your code. Temporal Cloud exposes usage metrics, and you can estimate Actions based on your Workflows’ structure: how many Activities per Workflow, how many retries, how many timers, and how chatty your system is with signals and queries.
Steps:
- Design your Workflows: Map your business process into Workflows and Activities (e.g., order placement → payment → shipment).
- Estimate interactions: Count major steps—Workflow starts, Activities, expected retries, timers, signals, and queries per execution.
- Map to usage: Use Temporal Cloud metrics and the pricing documentation to understand how those interactions translate into Actions per month.
What’s the difference between Active Storage and Retained Storage billing?
Short Answer: Active Storage covers Workflow histories for open and recently completed executions; Retained Storage covers histories you keep long-term for audit, debugging, or analytics.
Expanded Explanation:
Every Workflow execution in Temporal has a complete event history: every state transition, every Activity completion, every signal. Temporal’s durability comes from this history. It allows the system to replay and recover a Workflow from any failure point. This is what makes Workflows “as reliable as gravity”—you can crash a Worker, lose a pod, or hit a network partition, and Temporal simply replays from persisted history.
While a Workflow is running, its event history lives in Active Storage. After the Workflow completes, its history remains in Active Storage for a period (configurable through your cluster/namespace settings). During that window, you get fast access to histories for debugging, replay, or visibility through the Web UI. If you configure longer retention or archive data beyond that window, that history moves into Retained Storage, which is optimized and priced for long-term storage instead of active execution.
Cost-wise, this split lets you keep short-term, heavily accessed histories in Active Storage, and older data—kept for compliance, audit, or long-term analytics—in Retained Storage at a different price point.
Comparison Snapshot:
- Option A: Active Storage:
- Event histories for open Workflows and recently closed ones.
- Optimized for fast access and frequent replay.
- Option B: Retained Storage:
- Event histories kept beyond your “active” retention policy.
- Optimized/priced for long-term retention.
- Best for:
- Use Active Storage for day-to-day execution and debugging.
- Use Retained Storage for compliance, audits, and historical analysis.
How do I practically control and optimize my Temporal Cloud costs?
Short Answer: Control cost by designing Workflows with reasonable granularity, setting appropriate retention policies, and monitoring usage (Actions and storage) via Temporal Cloud metrics.
Expanded Explanation:
Cost in Temporal Cloud tracks complexity and volume. If you model every tiny function call as an Activity or keep every Workflow history forever, you’ll generate more Actions and storage. That may be exactly what you want for critical paths (moving money, compliance-sensitive operations) but overkill for simple tasks.
You have several levers: how you structure Workflows and Activities, how aggressively you use retries and heartbeats, how many signals and queries you generate, and how long you keep histories in Active vs Retained Storage. Temporal Cloud gives you observability into all of these—through metrics and the Web UI—so you can refine your design to hit the reliability you want at the cost you’re comfortable with.
What You Need:
- Well-structured Workflows/Activities:
- Avoid both extremes: giant monolithic Workflows with huge histories, and ultra-fine-grained Activities that explode Action counts.
- Use Activities for failure-prone, external operations (APIs, databases, external services); keep pure computation inside Workflow code.
- Explicit retention and monitoring:
- Set Workflow retention policies that match business needs.
- Use Temporal Cloud metrics and billing views to track Actions, Active Storage, and Retained Storage over time and adjust.
How should I think about Temporal Cloud pricing strategically vs. self-hosting?
Short Answer: With Temporal Cloud, you trade cluster management and capacity risk for a clean, usage-based bill tied to Actions and storage, usually reducing total cost once you factor in reliability work, on-call time, and database operations.
Expanded Explanation:
Without Temporal Cloud, you’re paying for hardware, database instances, and people. You over-provision clusters “just in case,” manage upgrades, tune Cassandra/PostgreSQL, and write custom repair scripts when things go wrong. You still don’t get guaranteed no-lost-progress behavior: you rely on ad-hoc state machines, scattered retry logic, and manual runbooks.
With Temporal Cloud, the creators of Temporal run the Service and handle high availability, failover, scaling, and upgrades. You get a bill that directly reflects how much reliable coordination you consumed: Actions and storage. You stop paying the hidden tax of state-machine complexity, debugging orphaned processes, and recovery work that doesn’t ship features.
For most teams, the strategic value is focus: you write Workflows and Activities as normal code, Temporal Cloud guarantees they run to completion, and your costs scale with usage. You don’t need to become experts in operating distributed workflow clusters; you just need to care about the reliability semantics and the workflows your product needs.
Why It Matters:
- Reduced operational toil:
- No cluster babysitting, database tuning, or homegrown retry/state logic.
- Fewer incidents and less time spent reconstructing what happened from logs.
- Cost aligned to value:
- You pay for coordination and durability at the point where it creates business value—per Workflow execution and its history—not per server or node.
Quick Recap
Temporal Cloud pricing is based on what you actually use: Actions that represent units of Workflow execution work, Active Storage for live and recently completed Workflow histories, and Retained Storage for long-term retention. Actions scale with how many Workflows you run and how complex they are (Activities, retries, timers, signals), while storage scales with how long and how deeply you keep execution history. You control costs by shaping your Workflow design and retention policies, and you avoid the operational overhead of running and scaling the Temporal Service yourself.