cost-optimization/actions-optimization

12 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Cost optimization through resource-based routing

GPU instances cost approximately $0.526/hr (g4dn.xlarge with NVIDIA T4) and should only handle ML training and inference. Standard CPU instances cost approximately $0.17/hr (c5.xlarge). High-memory instances cost approximately $0.504/hr (r5.2xlarge). Targeted resource allocation to appropriate instance types reduces infrastructure costs by 60-80% compared to running everything on GPU instances.

Local Activities billing when run back-to-back

Multiple Local Activities that run back-to-back only count as a single billable action, whereas each regular Activity counts as a billable action.

Local Activities retry behavior difference

If a specific Local Activity fails, all of them will be retried together, unlike regular Activities which can have independent retry control.

Heartbeat cost and usage guidelines

Each Heartbeat counts as one Action. Heartbeats should only be used for long-running Activities (10+ minutes) where you need to detect Worker failures and track progress. Short-running Activities that complete in seconds or minutes do not need Heartbeats.

Activity granularity tradeoff

Activity granularity is a fundamental architectural decision that impacts both costs and observability. More Activities provide better visibility and retry control but increase the Action count. Fewer Activities reduce costs but limit observability.

Child Workflows cost compared to Activities

Child Workflows cost 2 Actions compared to an Activity's 1 Action.

Default retry policy characteristics

Temporal's default Retry Policy uses 1s initial interval, 2.0 backoff coefficient, and unlimited maximum attempts. This can be aggressive and costly for expensive external operations.

Retry policy configuration for expensive operations

For expensive external operations like payment APIs, consider: setting MaximumAttempts to cap total retries, increasing InitialInterval (for example, to 10s) to reduce retry frequency, adding error types to NonRetryableErrorTypes for errors that won't resolve on retry (such as 4xx HTTP status codes), using next retry delay to dynamically control retry timing based on failure types, or implementing an Activity pause pattern to wait for manual intervention.

When to use regular Activities instead of local activities

Use Regular Activities instead of Local Activities if you require any of the following: Activities may take more than 10 seconds to complete, independent retry control for each Activity, need to avoid re-running expensive Activities when unrelated Activities fail, immediate Signal/Update handling during execution, or separate resource management (like rate limits) for each Activity.

Search Attributes billing at workflow start

Search Attributes provided at Workflow start do not count as billable Actions. If Search Attribute values are known before starting the Workflow, provide them at Workflow start to eliminate these costs entirely.

Search Attributes update billing

For Search Attributes that must be updated during Workflow Execution, each UpsertSearchAttributes call counts as 1 Action regardless of how many attributes are updated. Batch multiple related attribute updates into single operations to reduce Actions consumed.

Signal deduplication and batching for cost reduction

To optimize signal costs, implement deduplication logic client-side or aggregate data into fewer Signals. Use SignalWithStart instead of separate StartWorkflow and SignalWorkflow calls when initiating Workflows with Signals.

Give your agent this brain