temporalio · bechols · Feb 27, 2026
@@ -29,7 +29,7 @@ Activities are the most common Temporal primitive and encompass small units of w
 
 - Single write operations, like updating user information or submitting a credit card payment
 - Batches of similar writes, like creating multiple orders or sending multiple messages
-- One or more read operations followed by a write operation, like checking an product status and user address before updating an order status
+- One or more read operations followed by a write operation, like checking a product status and user address before updating an order status
 - A read that should be memoized, like an LLM call, a large download, or a slow-polling read
 
 Larger pieces of functionality should be broken up into multiple activities. This makes it easier to do failure recovery, have short timeouts, and be idempotent.

@@ -150,7 +150,7 @@ Activity Types are scoped through Task Queues.
 
 ## Best practices for defining Activities
 
-Here are some best practices you can use when you are creating an Activities for your Workflow:
+Here are some best practices you can use when you are creating Activities for your Workflow:
 
 - Activity arguments and return values should be serializable.
 - Activities that perform writes should be idempotent.

@@ -36,7 +36,7 @@ The Temporal CLI and the Web UI in turn provide built-in hooks to call the Codec
 ### Encoding data on the Web UI and CLI
 
 You can perform some operations on your Workflow Execution using the Temporal CLI and the Web UI.
-For example. you can start or signal an active Workflow Execution from the Temporal CLI or cancel a Workflow Execution from the Web UI, which might require inputs that contain sensitive data.
+For example, you can start or signal an active Workflow Execution from the Temporal CLI or cancel a Workflow Execution from the Web UI, which might require inputs that contain sensitive data.
 
 To encode this data, specify your [Codec Server endpoints](/codec-server) with the `codec-endpoint` parameter in [the Temporal CLI](/cli) and configure your Web UI to use the Codec Server endpoints.
 

@@ -228,7 +228,7 @@ Heartbeating is best thought about not in terms of time, but in terms of "How do
 For short-term operations, progress updates are not a requirement.
 However, checking the progress and status of Activity Executions that run over long periods is almost always useful.
 
-Consider the following when setting Activity Hearbeats:
+Consider the following when setting Activity Heartbeats:
 
 - Your underlying task must be able to report definite progress.
   Note that your Workflow cannot read this progress information while the Activity is still executing (or it would have to store it in Event History).

@@ -325,4 +325,4 @@ Remember that pretty much anything that interacts with the external world is inh
 **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be
 deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed
 above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities
-with have built-in support for retries.
+which have built-in support for retries.
@@ -338,4 +338,4 @@ Remember that pretty much anything that interacts with the external world is inh
 **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be
 deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed
 above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities
-with have built-in support for retries.
+which have built-in support for retries.
@@ -330,4 +330,4 @@ Remember that pretty much anything that interacts with the external world is inh
 **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be
 deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed
 above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities
-with have built-in support for retries.
+which have built-in support for retries.
@@ -332,4 +332,4 @@ Remember that pretty much anything that interacts with the external world is inh
 **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be
 deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed
 above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities
-with have built-in support for retries.
+which have built-in support for retries.
@@ -334,4 +334,4 @@ Remember that pretty much anything that interacts with the external world is inh
 **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be
 deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed
 above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities
-with have built-in support for retries.
+which have built-in support for retries.
@@ -61,7 +61,7 @@ See [errors in Nexus Operations](/references/failures#errors-in-nexus-operations
 A Nexus Operation Failure is delivered to the Workflow Execution when a Nexus Operation fails.
 It contains information about the failure and the Nexus Operation Execution; for example, the Nexus Operation name and
 Nexus Operation token.
-The reason for the failure is in the message and in the underlying cause is typically an Application Error or a Canceled Error.
+The reason for the failure is in the message, and the underlying cause is typically an Application Error or a Canceled Error.
 
 :::tip RESOURCES
 

@@ -152,7 +152,7 @@ For example, this may be done by looking at the Request-Timeout header or hookin
 
 Temporal Nexus Operations are requested and processed using the Temporal queue-based Worker architecture.
 Workers interact with their Namespace gRPC endpoint as before.
-Nexus Machinery on both sides handles the cross-namepace communication.
+Nexus Machinery on both sides handles the cross-namespace communication.
 
 <CaptionedImage
     src="/img/cloud/nexus/nexus-workers.png"

@@ -52,7 +52,7 @@ See [Configure Runtime Access Controls](/nexus/registry#configure-runtime-access
 
 :::info
 
-Temporal Cloud has built-in security connectivity across all Namespaces in an Account.
+Temporal Cloud has built-in secure connectivity across all Namespaces in an Account.
 
 Self-hosted deployments rely on the Temporal Cluster being secure.
 

@@ -9,7 +9,7 @@ tags:
 keywords:
   - nexus
   - nexus use cases
-  - nemporal nexus onboarding
+  - temporal nexus onboarding
   - setting up Nexus Endpoints
   - temporal cloud
   - nexus setup
@@ -27,7 +27,7 @@ Temporal Nexus is now [Generally Available](/evaluate/development-production-fea
 - **Cross-team, cross-domain, and cross-namespace** \-
   connect Temporal Applications within and across Namespaces.
 - **Share a subset of a Temporal Application** \-
-  abstract and share a subset of an Temporal Application as a Nexus Service.
+  abstract and share a subset of a Temporal Application as a Nexus Service.
 - **Modular design for growth** \-
   modular application design that can evolve as you grow.
 - **Smaller failure domains** \-

@@ -74,7 +74,7 @@ The following third-party SDKs exist but are not officially supported by Tempora
 
 ## Why use a Temporal SDK? {#why-use-an-sdk}
 
-Temporal SDKs empowers developers to concentrate on creating dependable and scalable business logic, alleviating the need to build home grown supervisor systems to ensure reliability and fault-tolerance. This is possible because the Temporal SDK provides a unified library that abstracts the intricacies of how Temporal handles distributed systems.
+Temporal SDKs empower developers to concentrate on creating dependable and scalable business logic, alleviating the need to build home-grown supervisor systems to ensure reliability and fault-tolerance. This is possible because the Temporal SDK provides a unified library that abstracts the intricacies of how Temporal handles distributed systems.
 
 ### Development pattern
 
@@ -419,7 +419,7 @@ func LoanCreditCheckActivity(ctx context.Context, loanAmount int) (string, error
 The Temporal Service functions more as a choreographer than a conductor. Rather than directly assigning tasks to Workers, the Temporal Service arranges the Tasks into a Task Queue while Workers poll the Task Queue. Developers may create a fleet of Workers and tune them so that a Task is picked up as soon as it is available. If a Worker goes down, Tasks can wait until the next Worker is available.
 
 A Workflow might request to execute an Activity, start a Timer, or start a Child Workflow, each of which translates into a Command, dispatched to the Temporal Service.
-In addition to acting on these Commands, the Temporal Service documents that interaction by appending their corresponding Events into to the Workflow Execution's Event History.
+In addition to acting on these Commands, the Temporal Service documents that interaction by appending their corresponding Events into the Workflow Execution's Event History.
 
 Take for instance the call to execute an Activity. When a Workflow invokes it, the Worker doesn't immediately execute that Activity code. Instead, it generates a ScheduleActivityTask Command, dispatching it to the Cluster. In response, the Cluster queues up a new Activity Task. Only when a Worker finds itself free, it collects the task and begins executing the Activity code.
 
@@ -458,7 +458,7 @@ func (a *Activities) NotifyApplicantActivity(ctx context.Context, input *NotifyA
 
 The Activity above is performing a single call to an external API. Since the call can fail due to transient issues, we define it outside of the Workflow and provide it with retry options.
 
-When you create a new Worker process, the Worker creates a long-lasting connection to the Temporal Service, polling a Task Queue for Tasks that related to the code it is capable of executing.
+When you create a new Worker process, the Worker creates a long-lasting connection to the Temporal Service, polling a Task Queue for Tasks that are related to the code it is capable of executing.
 
 <CaptionedImage
     src="/diagrams/how-sdk-works-1.svg"
@@ -490,7 +490,7 @@ When the call to invoke the Activity is evaluated, the Worker suspends executing
 
 When the Worker process can perform more work, it picks up the Activity Task and begins executing the Activity code, which includes the call to the external API.
 
-If the Activity fails, say the API goes down, Temporal will automatically retry the Activity with one second between intervals, as the configurations have defined, an infinite amount of times until the Activity succeeds or is canceled.
+If the Activity fails, say the API goes down, Temporal will automatically retry the Activity with one second between intervals, as the configurations have defined, an infinite number of times until the Activity succeeds or is canceled.
 
 In the case where the calls succeeds, and the code completes, the Worker tells the Temporal Service the Activity Task completed.
 
@@ -506,7 +506,7 @@ The Temporal Service creates a new Workflow Task which the Worker picks up.
     src="/diagrams/how-sdk-works-1.svg"
     title="The Worker picks up the new Task" />
 
-This is when the SDK Worker Replays the Workflow code, uses the Event History as guidance on what to expect. If the Replay encounters an Event that doesn't match up with what is expected from the code, a [non-determinism](/references/errors#non-deterministic-error) error gets thrown.
+This is when the SDK Worker Replays the Workflow code, using the Event History as guidance on what to expect. If the Replay encounters an Event that doesn't match up with what is expected from the code, a [non-determinism](/references/errors#non-deterministic-error) error gets thrown.
 
 If there is alignment, the Worker continues evaluating code.
 

@@ -201,7 +201,7 @@ Search Attributes available in your Visibility store can be used with Workflow E
 To actually have results from the use of a [List Filter](/list-filter), Search Attributes must be added to a Workflow Execution as metadata.
 
 - To create custom Search Attributes in your Visibility store, see [Create custom Search Attributes](/self-hosted-guide/visibility#create-custom-search-attributes).
-- To remove a custom Search Attribute from the Visbility store, see [Remove custom Search Attributes](/self-hosted-guide/visibility#remove-custom-search-attributes).
+- To remove a custom Search Attribute from the Visibility store, see [Remove custom Search Attributes](/self-hosted-guide/visibility#remove-custom-search-attributes).
   Removing custom Search Attributes is not supported on Temporal Cloud.
 - To rename a custom Search Attribute on Temporal Cloud, see [`tcld namespace search-attributes rename`](/cloud/tcld/namespace/#rename).
 

@@ -117,7 +117,7 @@ By default, both Task Queues and Workers are in an unversioned state.
 To use this feature, both the Task Queue and the Worker must be associated with Build IDs.
 
 If you run a Worker using versioning against a Task Queue that has not been set up to use versioning (or is missing that Worker's Build ID), it won't get any tasks.
-Likewise, a unversioned Worker polling a Task Queue with versioning won't work either.
+Likewise, an unversioned Worker polling a Task Queue with versioning won't work either.
 
 :::note Versions don't need to follow semver or any other semantic versioning scheme!
 
@@ -140,7 +140,7 @@ If Workflows that don't have an assigned version are still running on the Task Q
 So ensure that such Workers are still operational if any Workflows were open when you added the first version.
 If you deployed any Workers with a _different_ version, those Workers receive no Tasks.
 
-Now, imagine you need change the Workflow for some reason.
+Now, imagine you need to change the Workflow for some reason.
 
 Add `2.0` to the sets as the new default:
 
@@ -196,7 +196,7 @@ A request to change the sets can do one of the following:
 - Promote a version within an existing set to become the default for that set.
 - Promote a set to become the overall-default set.
 
-You can't explicitly delete versions.This helps you avoid the situation in which Workflows accidentally become stuck with no means of making progress because the version they're associated with no longer exists.
+You can't explicitly delete versions. This helps you avoid the situation in which Workflows accidentally become stuck with no means of making progress because the version they're associated with no longer exists.
 
 However, sometimes you might want to do this intentionally.
 If you _want_ to make sure that all Workflows currently being processed by, say, `2.0` stop (even if you don't yet have a new version ready), you can add a new version `2.1` to the sets marked as compatible with `2.0`.

@@ -166,7 +166,7 @@ Temporal Worker triggers the registered Operation handler based on the Nexus tas
 ### What is a Nexus Task Execution? {#nexus-task-execution}
 
 A Nexus Task Execution occurs when a Worker uses the context provided from the Nexus Task and executes an action
-associated with a Nexus Operation which commonly includes starting a Nexus Operation using it's Nexus Operation handler
+associated with a Nexus Operation which commonly includes starting a Nexus Operation using its Nexus Operation handler
 plus many additional actions that may be performed on a Nexus Operation.
 
 The NexusOperationScheduled Event corresponds to when the Temporal Service records the Workflow's intent to schedule an

@@ -51,7 +51,7 @@ A **Pinned** Workflow is guaranteed to complete on a single Worker Deployment Ve
 
 An **Auto-Upgrade** Workflow will move to the latest Worker Deployment Version automatically whenever you change the current version. Auto-upgrade Workflows are not restricted to a single Deployment Version and need to be kept replay-safe manually, i.e. with [patching](/workflow-definition#workflow-versioning).
 
-### Actvity behavior across versions
+### Activity behavior across versions
 
 There are a few scenarios to consider for your Activities when you're handling your Worker Deployment versions.
 

@@ -204,7 +204,7 @@ It is important to note that the [status](/workflow-execution#workflow-execution
 A scheduled Workflow Execution may complete with a result up to the maximum blob size (2 MiB by default).
 However, due to internal limitations, results that are within 1 KiB of this limit cannot be passed to the next execution.
 So, for example, a Workflow Execution that returns a result of size 2,096,640 bytes (which is above 2MiB - 1KiB limit)
-will be allowed to compete successfully, but that value will not be available as a last completion result.
+will be allowed to complete successfully, but that value will not be available as a last completion result.
 This limitation may be lifted in the future.
 
 :::

@@ -15,7 +15,7 @@ tags:
 
 import { CaptionedImage } from '@site/src/components';
 
-This pages covers the following:
+This page covers the following:
 
 - [What is a Workflow Definition?](/workflow-definition)
 - [Determinism and constraints](#deterministic-constraints)
-Original file line number
+Diff line change
@@ Expand Up @@
     :::info
-    Temporal Cloud has built-in security connectivity across all Namespaces in an Account.
+    Temporal Cloud has built-in secure connectivity across all Namespaces in an Account.
     Self-hosted deployments rely on the Temporal Cluster being secure.
@@ Expand Down @@