From cee8602ccce9bb22678f5ec6df8ea2d92e0f8063 Mon Sep 17 00:00:00 2001 From: Lenny Chen Date: Tue, 12 May 2026 14:42:32 -0700 Subject: [PATCH 1/3] docs: clarify replay doesn't count as actions --- docs/evaluate/temporal-cloud/actions.mdx | 212 ++++++++++++----------- 1 file changed, 114 insertions(+), 98 deletions(-) diff --git a/docs/evaluate/temporal-cloud/actions.mdx b/docs/evaluate/temporal-cloud/actions.mdx index bb9ae37090..2c3eb03118 100644 --- a/docs/evaluate/temporal-cloud/actions.mdx +++ b/docs/evaluate/temporal-cloud/actions.mdx @@ -21,8 +21,8 @@ tags: - Support --- -Temporal Cloud Actions are the primary unit of consumption-based pricing for Temporal Cloud. -They track billable operations within the Temporal Cloud Service, such as starting Workflows, recording a Heartbeat, or sending Signals. +Temporal Cloud Actions are the primary unit of consumption-based pricing for Temporal Cloud. They track billable +operations within the Temporal Cloud Service, such as starting Workflows, recording a Heartbeat, or sending Signals. Actions can be largely placed in the following categories: @@ -41,66 +41,74 @@ Some additional Temporal Cloud features are billed as Actions: - [Fairness](#fairness) - [Capacity](#capacity) -Billable Actions are visible in the [OpenMetrics endpoint](https://metrics.temporal.io), [Workflow History](/cloud/actions-usage#actions-in-workflows) and [Usage](https://cloud.temporal.io/usage) Dashboards, and the [Billing API](/cloud/billing-api). -Action types and categories can help estimate usage, identify specific Action types that are driving usage, optimize workflows by tracking usage spikes, and troubleshoot errors. -For example: +Actions that occur during [Workflow Replay](/workflow-execution/replay) do not count towards billed Actions. Replay +reconstructs Workflow state from Event History and does not generate new server-side operations. + +Billable Actions are visible in the [OpenMetrics endpoint](https://metrics.temporal.io), +[Workflow History](/cloud/actions-usage#actions-in-workflows) and [Usage](https://cloud.temporal.io/usage) Dashboards, +and the [Billing API](/cloud/billing-api). Action types and categories can help estimate usage, identify specific Action +types that are driving usage, optimize workflows by tracking usage spikes, and troubleshoot errors. For example: - You can see if a new Workflow type on a Namespace is driving a significant usage increase - You can identify the aggregate usage of Activity Heartbeats on a Namespace -The following is the mapping of Action Categories to Action types. -The Action Types that are visible on various endpoints can differ based what is visible to a system. -Note: Action Categories and Action Types are not available in the billing API. +The following is the mapping of Action Categories to Action types. The Action Types that are visible on various +endpoints can differ based on what is visible to a system. Action Categories and Action Types are not available in the +billing API. -Usage and Billing data will have the most complete Actions data while Workflow history and metrics will help with detailed _estimates_. -For example, [History Event Types](https://docs.temporal.io/workflow-execution/event) are provided for transparency, but do not always have a simple 1:1 relationship with Action Types. -The Categories, Action types, and available endpoints are listed in the following sections: +Usage and Billing data will have the most complete Actions data while Workflow history and metrics will help with +detailed _estimates_. For example, [History Event Types](https://docs.temporal.io/workflow-execution/event) are provided +for transparency, but do not always have a simple 1:1 relationship with Action Types. The Categories, Action types, and +available endpoints are listed in the following sections: ## Workflow {#workflow} - **Workflow started** - - Occurs via client start, [Continue-As-New](/workflow-execution/continue-as-new), [Child Workflow](/child-workflows) start. - - If a Workflow start fails, an Action is not recorded. + - Occurs via client start, [Continue-As-New](/workflow-execution/continue-as-new), [Child Workflow](/child-workflows) + start. + - If a Workflow start fails, an Action is not recorded. - De-duplicated Workflow starts that share a Workflow ID do _not_ count as an Action. - **Workflow reset** - - Occurs when a [Workflow](/workflows) is reset. - - Actions that occur before a [Reset](/workflow-execution/event#reset) are counted on the original workflow. - These events are not counted on the newly created workflow. + - Occurs when a [Workflow](/workflows) is reset. + - Actions that occur before a [Reset](/workflow-execution/event#reset) are counted on the original workflow. These + events are not counted on the newly created workflow. - **Search Attribute upsert requested** - - Occurs for each invocation of `UpsertSearchAttributes` command. - - Multiple Search Attributes updated in a single `UpsertSearchAttributes` command count as one Action. - - Search Attributes specified during Workflow start are _excluded_ from Action counts. + - Occurs for each invocation of `UpsertSearchAttributes` command. + - Multiple Search Attributes updated in a single `UpsertSearchAttributes` command count as one Action. + - Search Attributes specified during Workflow start are _excluded_ from Action counts. - The `TemporalChangeVersion` Search Attribute, used for Workflow versioning, is also exempt from Action counting. -- **Workflow Execution Options updated.** - - Occurs for every [Workflow-Execution-Options-Updated](/references/events#workflowexecutionoptionsupdated) event. +- **Workflow Execution Options updated.** + - Occurs for every [Workflow-Execution-Options-Updated](/references/events#workflowexecutionoptionsupdated) event. - This includes attaching a Workflow completion callback or modifying a Workflow versioning override. - **Start Child Workflow Execution initiated.** - - Occurs when the parent Workflow durably records the intent to start a Child Workflow. - - Results in two Actions, one for durably storing the intent to start a Child Workflow and one for the attempt to start it. + - Occurs when the parent Workflow durably records the intent to start a Child Workflow. + - Results in two Actions, one for durably storing the intent to start a Child Workflow and one for the attempt to + start it. - **Workflow started via Multi-Operation.** - - Occurs when a Workflow is started as part of an ExecuteMultiOperation request — a single atomic RPC that bundles a Workflow start with one or more Workflow Updates. - The start counts as one Action. - - Each bundled Update that is accepted or rejected counts as an additional Action. - - If the Workflow was already running and the start is de-duplicated, no Action is charged for the start (though an `update_workflow_options_via_start` Action may still apply). - -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Start Workflow | `start_workflow` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` | -| Start Child Workflow | `start_child_workflow` | `EVENT_TYPE_START_CHILD_WORKFLOW_EXECUTION_INITIATED` | -| Continue As New Workflow | `continue_as_new_workflow` | `EVENT_TYPE_WORKFLOW_EXECUTION_CONTINUED_AS_NEW` Note: The UI shows a billable action only for the `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` event of the newly started Workflow, not for this history event. | -| Start Workflow (Multi-Operation) | `start_workflow_multi_operation` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` | -| Update Workflow Options | `update_workflow_options` | `EVENT_TYPE_WORKFLOW_EXECUTION_OPTIONS_UPDATED` | -| Update Workflow Options (Via Start) | `update_workflow_options_via_start` | `EVENT_TYPE_WORKFLOW_EXECUTION_OPTIONS_UPDATED` | -| Upsert Workflow Search Attributes | `upsert_workflow_search_attributes` | `EVENT_TYPE_UPSERT_WORKFLOW_SEARCH_ATTRIBUTES` | -| Reset Workflow | `reset_workflow` | `EVENT_TYPE_WORKFLOW_TASK_FAILED` Note: When `cause == WORKFLOW_TASK_FAILED_CAUSE_RESET_WORKFLOW` | -| Record Workflow Heartbeat | `record_workflow_heartbeat` | N/A | + - Occurs when a Workflow is started as part of an ExecuteMultiOperation request — a single atomic RPC that bundles a + Workflow start with one or more Workflow Updates. The start counts as one Action. + - Each bundled Update that is accepted or rejected counts as an additional Action. + - If the Workflow was already running and the start is de-duplicated, no Action is charged for the start (though an + `update_workflow_options_via_start` Action may still apply). + +| Usage Name | Metric Name | History Event Type | +| ----------------------------------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Start Workflow | `start_workflow` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` | +| Start Child Workflow | `start_child_workflow` | `EVENT_TYPE_START_CHILD_WORKFLOW_EXECUTION_INITIATED` | +| Continue As New Workflow | `continue_as_new_workflow` | `EVENT_TYPE_WORKFLOW_EXECUTION_CONTINUED_AS_NEW` Note: The UI shows a billable action only for the `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` event of the newly started Workflow, not for this history event. | +| Start Workflow (Multi-Operation) | `start_workflow_multi_operation` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` | +| Update Workflow Options | `update_workflow_options` | `EVENT_TYPE_WORKFLOW_EXECUTION_OPTIONS_UPDATED` | +| Update Workflow Options (Via Start) | `update_workflow_options_via_start` | `EVENT_TYPE_WORKFLOW_EXECUTION_OPTIONS_UPDATED` | +| Upsert Workflow Search Attributes | `upsert_workflow_search_attributes` | `EVENT_TYPE_UPSERT_WORKFLOW_SEARCH_ATTRIBUTES` | +| Reset Workflow | `reset_workflow` | `EVENT_TYPE_WORKFLOW_TASK_FAILED` Note: When `cause == WORKFLOW_TASK_FAILED_CAUSE_RESET_WORKFLOW` | +| Record Workflow Heartbeat | `record_workflow_heartbeat` | N/A | ## Activity {#activity} - **Activity started or retried**. Occurs each time an Activity is started or retried. - **Local Activity started**. All [Local Activities](/local-activity) associated with one Workflow Task count as a - single Action. Temporal Cloud counts all [RecordMarkers](/references/commands#recordmarker) from each - Workflow Task as one action, and not _N_ actions. Note: + single Action. Temporal Cloud counts all [RecordMarkers](/references/commands#recordmarker) from each Workflow Task as + one action, and not _N_ actions. Note: - Each Workflow Task Heartbeat counts as an additional Action. - Local Activities retried following a Workflow Task Heartbeat count as one Action (capped at 100 Actions). - **Activity Heartbeat recorded**. A Heartbeat call from Activity code counts as an Action only if it reaches the @@ -109,58 +117,65 @@ The Categories, Action types, and available endpoints are listed in the followin the [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout). Heartbeats don't apply to Local Activities. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Schedule Activity | `schedule_activity` | `EVENT_TYPE_ACTIVITY_TASK_SCHEDULED` | -| Retry Activity | `retry_activity` | `EVENT_TYPE_ACTIVITY_TASK_STARTED` Note: Intermediate retry attempts do not produce separate history events. Total attempt count is recorded in the `ActivityTaskStartedEventAttributes.attempt` field on this event. The user should subtract 1, because the first attempt is not a retry. If the Workflow is terminated while Activity retry is in progress, this `STARTED` event is not written, so this data may not always be available. | -| Retry Local Activity | `retry_activity_local` | `EVENT_TYPE_WORKFLOW_TASK_COMPLETED ` Note: the retry count is recorded in `WorkflowTaskCompletedEventAttributes.metering_metadata.nonfirst_local_activity_execution_attempts` field on this event. | -| Record Activity Heartbeat | `record_activity_heartbeat` | N/A | -| Record Activity Heartbeat by ID | `record_activity_heartbeat_by_id` | N/A | -| Record Activity Markers | `record_activity_markers` | `EVENT_TYPE_MARKER_RECORDED` | -| Start Standalone Activity | `start_standalone_activity` | N/A | -| Retry Standalone Activity | `retry_standalone_activity` | N/A | -| Record Standalone Activity Heartbeat | `record_standalone_activity_heartbeat` | N/A | -| Record Standalone Activity Heartbeat By ID | `record_standalone_activity_heartbeat_by_id` | N/A | +| Usage Name | Metric Name | History Event Type | +| ------------------------------------------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Schedule Activity | `schedule_activity` | `EVENT_TYPE_ACTIVITY_TASK_SCHEDULED` | +| Retry Activity | `retry_activity` | `EVENT_TYPE_ACTIVITY_TASK_STARTED` Note: Intermediate retry attempts do not produce separate history events. Total attempt count is recorded in the `ActivityTaskStartedEventAttributes.attempt` field on this event. The user should subtract 1, because the first attempt is not a retry. If the Workflow is terminated while Activity retry is in progress, this `STARTED` event is not written, so this data may not always be available. | +| Retry Local Activity | `retry_activity_local` | `EVENT_TYPE_WORKFLOW_TASK_COMPLETED ` Note: the retry count is recorded in `WorkflowTaskCompletedEventAttributes.metering_metadata.nonfirst_local_activity_execution_attempts` field on this event. | +| Record Activity Heartbeat | `record_activity_heartbeat` | N/A | +| Record Activity Heartbeat by ID | `record_activity_heartbeat_by_id` | N/A | +| Record Activity Markers | `record_activity_markers` | `EVENT_TYPE_MARKER_RECORDED` | +| Start Standalone Activity | `start_standalone_activity` | N/A | +| Retry Standalone Activity | `retry_standalone_activity` | N/A | +| Record Standalone Activity Heartbeat | `record_standalone_activity_heartbeat` | N/A | +| Record Standalone Activity Heartbeat By ID | `record_standalone_activity_heartbeat_by_id` | N/A | ## Timer {#timer} -- **Timer started**. Includes implicit Timers that are started by a Temporal SDK when timeouts are set, such as `AwaitWithTimeout` in Go or `condition` in TypeScript. +- **Timer started**. Includes implicit Timers that are started by a Temporal SDK when timeouts are set, such as + `AwaitWithTimeout` in Go or `condition` in TypeScript. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | +| Usage Name | Metric Name | History Event Type | +| ----------- | ------------- | -------------------------- | | Start Timer | `start_timer` | `EVENT_TYPE_TIMER_STARTED` | ## Signal {#signal} -- **Signal sent**. An Action occurs for every [Signal](https://docs.temporal.io/sending-messages#sending-signals), whether sent from a Client or from a Workflow. -Also, one total action occurs for any [Signal-With-Start](https://docs.temporal.io/sending-messages#signal-with-start), regardless of whether the Workflow starts. +- **Signal sent**. An Action occurs for every [Signal](https://docs.temporal.io/sending-messages#sending-signals), + whether sent from a Client or from a Workflow. Also, one total action occurs for any + [Signal-With-Start](https://docs.temporal.io/sending-messages#signal-with-start), regardless of whether the Workflow + starts. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Signal Workflow | `signal_workflow` | `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` | -| Signal External Workflow | `signal_external_workflow` | `EVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED` (signaler workflow history) `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` (signaled Workflow history) Note: The UI shows a billable action only in the signaled Workflow history, not in the signaler Workflow history. | -| Signal Workflow With Start | `signal_workflow_with_start` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` followed by `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` if the workflow didn’t exist, or only `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` if the Workflow existed.| +| Usage Name | Metric Name | History Event Type | +| -------------------------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Signal Workflow | `signal_workflow` | `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` | +| Signal External Workflow | `signal_external_workflow` | `EVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED` (signaler workflow history) `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` (signaled Workflow history) Note: The UI shows a billable action only in the signaled Workflow history, not in the signaler Workflow history. | +| Signal Workflow With Start | `signal_workflow_with_start` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` followed by `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` if the workflow didn’t exist, or only `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` if the Workflow existed. | ## Query {#query} -- **Query received by Worker**. An Action occurs for every [Query](https://docs.temporal.io/sending-messages#sending-queries), including viewing the call stack in the Temporal Cloud UI, which results in a Query behind the scenes. -`__temporal_workflow_metadata` is a built-in query used to retrieve workflow metadata at runtime and is excluded. +- **Query received by Worker**. An Action occurs for every + [Query](https://docs.temporal.io/sending-messages#sending-queries), including viewing the call stack in the Temporal + Cloud UI, which results in a Query behind the scenes. `__temporal_workflow_metadata` is a built-in query used to + retrieve workflow metadata at runtime and is excluded. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Query Workflow | `query_workflow` | N/A | +| Usage Name | Metric Name | History Event Type | +| -------------- | ---------------- | ------------------ | +| Query Workflow | `query_workflow` | N/A | ## Update {#update} -- **Update received by Worker**. - - Occurs for every successful [Update](https://docs.temporal.io/sending-messages#sending-updates) and every [rejected](https://docs.temporal.io/handling-messages#update-validators) Update. - - This includes [Update-With-Start](https://docs.temporal.io/sending-messages#update-with-start), and is in addition to the start Action in the case when the Workflow starts as well. - - De-duplicated Updates that share an Update ID do *not* count as an Action. +- **Update received by Worker**. + - Occurs for every successful [Update](https://docs.temporal.io/sending-messages#sending-updates) and every + [rejected](https://docs.temporal.io/handling-messages#update-validators) Update. + - This includes [Update-With-Start](https://docs.temporal.io/sending-messages#update-with-start), and is in addition + to the start Action in the case when the Workflow starts as well. + - De-duplicated Updates that share an Update ID do _not_ count as an Action. -| Name | Action ID | History Event Type | -| ----- | ----- | ----- | -| Accept Workflow Update | `accept_workflow_update` | `EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_ACCEPTED` | -| Reject Workflow Update | `reject_workflow_update` | `EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_REJECTED` Note: this event is never written to history.| +| Name | Action ID | History Event Type | +| ---------------------- | ------------------------ | --------------------------------------------------------------------------------------------- | +| Accept Workflow Update | `accept_workflow_update` | `EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_ACCEPTED` | +| Reject Workflow Update | `reject_workflow_update` | `EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_REJECTED` Note: this event is never written to history. | ## Schedule {#schedule} @@ -171,15 +186,14 @@ accrues three actions: - **Workflow started**. This is a single action to start the target Workflow. It includes initial Search Attributes as part of the start request. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Create Schedule | `create_schedule` | N/A | -| Update Schedule | `update_schedule` | N/A | -| Patch Schedule | `patch_schedule` | N/A | -| Delete Schedule | `delete_schedule` | N/A | +| Usage Name | Metric Name | History Event Type | +| ----------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Create Schedule | `create_schedule` | N/A | +| Update Schedule | `update_schedule` | N/A | +| Patch Schedule | `patch_schedule` | N/A | +| Delete Schedule | `delete_schedule` | N/A | | Schedule Workflow | `schedule_workflow` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` Note: `event.WorkflowExecutionStartedEventAttributes.indexedFields.TemporalScheduledById` tells if a Workflow was started by a Schedule. | - ## Temporal Nexus {#nexus} - For [Nexus Operation scheduled](/references/events#nexusoperationscheduled), the caller Workflow starting a Nexus @@ -191,9 +205,9 @@ accrues three actions: includes retries for underlying Temporal primitives like Activities but _not_ for handling the Nexus Operation itself or a retry of the Nexus Operation itself. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Schedule Nexus Operation | `schedule_nexus_operation` | `EVENT_TYPE_NEXUS_OPERATION_SCHEDULED` | +| Usage Name | Metric Name | History Event Type | +| ------------------------------------ | -------------------------------------- | --------------------------------------------- | +| Schedule Nexus Operation | `schedule_nexus_operation` | `EVENT_TYPE_NEXUS_OPERATION_SCHEDULED` | | Request Nexus Operation Cancellation | `request_nexus_operation_cancellation` | `EVENT_TYPE_NEXUS_OPERATION_CANCEL_REQUESTED` | ## Export {#export} @@ -204,18 +218,20 @@ choice. - **Workflow exported**. Each Workflow exported accrues a single action. - Excluded from APS calculations. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Export Workflow History | N/A | N/A | +| Usage Name | Metric Name | History Event Type | +| ----------------------- | ----------- | ------------------ | +| Export Workflow History | N/A | N/A | ## Fairness {#fairness} -For each hour a Namespace has the [Fairness](/develop/task-queue-priority-fairness#task-queue-fairness) feature enabled, an additional `0.1` Action is charged per Action in the Namespace. +For each hour a Namespace has the [Fairness](/develop/task-queue-priority-fairness#task-queue-fairness) feature enabled, +an additional `0.1` Action is charged per Action in the Namespace. + - Excluded from APS calculations. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Enable Fairness | N/A | N/A | +| Usage Name | Metric Name | History Event Type | +| --------------- | ----------- | ------------------ | +| Enable Fairness | N/A | N/A | ## Capacity {#capacity} @@ -223,9 +239,9 @@ For each hour a Namespace has the [Fairness](/develop/task-queue-priority-fairne TRUs in any hour where TRUs are set and actual usage falls beneath the included hourly Action allocation. - Excluded from APS calculations. -| Usage Name | Metric Name | History Event Type | -| ----- | ----- | ----- | -| Enable Provisioned Capacity | N/A | N/A | +| Usage Name | Metric Name | History Event Type | +| --------------------------- | ----------- | ------------------ | +| Enable Provisioned Capacity | N/A | N/A | -Actions usage can be tracked in multiple areas depending on the needed granularity. -Refer to the [Billing and Usage](/cloud/billing-and-usage) documentation for more information. +Actions usage can be tracked in multiple areas depending on the needed granularity. Refer to the +[Billing and Usage](/cloud/billing-and-usage) documentation for more information. From 989b198c311b349a28dc8f661b47dc978ce61c49 Mon Sep 17 00:00:00 2001 From: Lenny Chen Date: Tue, 12 May 2026 14:44:57 -0700 Subject: [PATCH 2/3] fix broken link --- docs/evaluate/temporal-cloud/actions.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/evaluate/temporal-cloud/actions.mdx b/docs/evaluate/temporal-cloud/actions.mdx index 2c3eb03118..2bc11e06c1 100644 --- a/docs/evaluate/temporal-cloud/actions.mdx +++ b/docs/evaluate/temporal-cloud/actions.mdx @@ -41,7 +41,7 @@ Some additional Temporal Cloud features are billed as Actions: - [Fairness](#fairness) - [Capacity](#capacity) -Actions that occur during [Workflow Replay](/workflow-execution/replay) do not count towards billed Actions. Replay +Actions that occur during [Workflow Replay](/workflow-execution#replay) do not count towards billed Actions. Replay reconstructs Workflow state from Event History and does not generate new server-side operations. Billable Actions are visible in the [OpenMetrics endpoint](https://metrics.temporal.io), From fada5fe88231c4692e9a35a721abbc013538f210 Mon Sep 17 00:00:00 2001 From: Lenny Chen Date: Tue, 12 May 2026 14:47:04 -0700 Subject: [PATCH 3/3] small clarification --- docs/evaluate/temporal-cloud/actions.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/evaluate/temporal-cloud/actions.mdx b/docs/evaluate/temporal-cloud/actions.mdx index 2bc11e06c1..6f58030573 100644 --- a/docs/evaluate/temporal-cloud/actions.mdx +++ b/docs/evaluate/temporal-cloud/actions.mdx @@ -42,7 +42,8 @@ Some additional Temporal Cloud features are billed as Actions: - [Capacity](#capacity) Actions that occur during [Workflow Replay](/workflow-execution#replay) do not count towards billed Actions. Replay -reconstructs Workflow state from Event History and does not generate new server-side operations. +happens only on the Worker side to reconstruct Workflow state from Event History and does not generate new server-side +operations. Billable Actions are visible in the [OpenMetrics endpoint](https://metrics.temporal.io), [Workflow History](/cloud/actions-usage#actions-in-workflows) and [Usage](https://cloud.temporal.io/usage) Dashboards,