temporalio · flippedcoder · Aug 20, 2026 · Aug 20, 2026 · Aug 24, 2026 · Aug 24, 2026
@@ -123,7 +123,7 @@ need its own service accounts, API keys, dashboards, or rate limits. If that is
 [Namespace best practices](/best-practices/managing-namespace) before committing to Namespace-per-tenant isolation.
 
 <RelatedReadContainer>
-  <RelatedReadItem path="/evaluate/development-production-features/multi-tenancy#namespace-isolation" text="Namespace Isolation in Temporal Cloud" archetype="cloud-guide" />
+  <RelatedReadItem path="/evaluate/features/multi-tenancy#namespace-isolation" text="Namespace Isolation in Temporal Cloud" archetype="cloud-guide" />
 </RelatedReadContainer>
 
 ### Pattern comparison
@@ -336,7 +336,7 @@ TenantId = 'customer-123' AND ExecutionStatus = 'Running'
 ## Related resources
 
 <RelatedReadContainer>
-  <RelatedReadItem path="/evaluate/development-production-features/multi-tenancy" text="Multi-tenancy Overview" archetype="feature-guide" />
+  <RelatedReadItem path="/evaluate/features/multi-tenancy" text="Multi-tenancy Overview" archetype="feature-guide" />
   <RelatedReadItem path="/cloud/limits" text="Temporal Cloud Limits" archetype="cloud-guide" />
   <RelatedReadItem path="/visibility" text="Visibility and Search Attributes" archetype="feature-guide" />
 </RelatedReadContainer>
@@ -228,7 +228,7 @@ Intentionally break or degrade downstream dependencies used by Activities:
 
 - [Workflow Versioning Strategies - Developer Corner](https://community.temporal.io/t/workflow-versioning-strategies/6911)
 - [Worker Versioning](/production-deployment/worker-deployments/worker-versioning)
-- [Replay Testing](/evaluate/development-production-features/testing-suite)
+- [Replay Testing](/evaluate/features/testing-suite)
 
 **What to test**
 
@@ -251,7 +251,7 @@ Intentionally break or degrade downstream dependencies used by Activities:
 
 - [Workflow Versioning Strategies - Developer Corner](https://community.temporal.io/t/workflow-versioning-strategies/6911)
 - [Worker Versioning](/production-deployment/worker-deployments/worker-versioning)
-- [Replay Testing](/evaluate/development-production-features/testing-suite)
+- [Replay Testing](/evaluate/features/testing-suite)
 
 **What to test**
 

@@ -92,7 +92,7 @@ extension using the following command:
 
 :::tip Support, stability, and dependency info
 
-The Temporal Cloud extension is in [Pre-release](/evaluate/development-production-features/release-stages#pre-release).
+The Temporal Cloud extension is in [Pre-release](/evaluate/features/release-stages#pre-release).
 APIs and configuration may change before the stable release.
 
 :::

@@ -248,7 +248,7 @@ key and mTLS authentication on the same Namespace, please contact
 :::info
 
 Using **both** API key and mTLS authentication on the **same** Namespace is in
-[pre-release](/evaluate/development-production-features/release-stages) and doesn't support
+[pre-release](/evaluate/features/release-stages) and doesn't support
 [High Availability features](/cloud/high-availability) or authenticating with an API Key to a Namespace Endpoint.
 
 :::

@@ -131,7 +131,7 @@ These are often major concerns for financial services, e-commerce, gaming, globa
 
 In selected regions, you can add a replica to a Namespace in the same region.
 Temporal operates a "cell architecture" and will replicate the Namespace across multiple cells in that region.
-This feature is currently in [Public Preview](/evaluate/development-production-features/release-stages) in selected regions.
+This feature is currently in [Public Preview](/evaluate/features/release-stages) in selected regions.
 
 Failovers between cells are always managed automatically by Temporal. Unlike Multi-region and Multi-cloud Replication, you cannot disable automatic failovers and you cannot trigger a manual failover for a Same-region Replication Namespace. See [Failovers](/cloud/high-availability/failovers) for details.
 

@@ -17,7 +17,7 @@ import { StandaloneActivityDemo, ReleaseNoteHeader, SdkGuideLinks } from '@site/
   languages={["Go", "Python", "Java", ".NET", "TypeScript", "Ruby"]}
   guidePath="activities/standalone-activities"
 >
-  Available in [Temporal Cloud](/standalone-activity#temporal-cloud-support) and in the [Temporal CLI](/standalone-activity#temporal-cli-support) v1.7.0 or higher with Temporal Server v1.31.0 or higher. Java SDK support is in [Pre-release](/evaluate/development-production-features/release-stages#pre-release).
+  Available in [Temporal Cloud](/standalone-activity#temporal-cloud-support) and in the [Temporal CLI](/standalone-activity#temporal-cli-support) v1.7.0 or higher with Temporal Server v1.31.0 or higher. Java SDK support is in [Pre-release](/evaluate/features/release-stages#pre-release).
 </ReleaseNoteHeader>
 
 Standalone Activities let you run a single Activity straight from your application without

@@ -192,7 +192,7 @@ requirements:
   meaning it produces the same commands and results when replayed. For example, don't call system time APIs, generate
   random values, or perform direct network and file I/O from Workflow-context code; move that work to Activities or
   Nexus Operations.
-- See [observability](/evaluate/development-production-features/observability) to avoid duplicating observation side
+- See [observability](/evaluate/features/observability) to avoid duplicating observation side
   effects when Workflows replay.
 - Put other side effects inside of Activities or [Local Activities](/local-activity). This helps your Workflow handle
   being restarted, resumed, or executed in a different process from where it originally began without losing correctness
@@ -209,7 +209,7 @@ queues and Workers.
 Users use Workflows for:
 
 - Orchestration and decision-making
-- Interactivity via [message-passing](/evaluate/development-production-features/workflow-message-passing)
+- Interactivity via [message-passing](/evaluate/features/workflow-message-passing)
 - Tracing and observability
 
 #### Making changes to your library

@@ -304,7 +304,7 @@ To send an Update to a Workflow Execution, you can:
 
 :::tip Stability
 
-In [Public Preview](/evaluate/development-production-features/release-stages#public-preview) in Temporal Cloud.
+In [Public Preview](/evaluate/features/release-stages#public-preview) in Temporal Cloud.
 
 Minimum Temporal Server version [Temporal Server version 1.26](https://github.com/temporalio/temporal/releases/tag/v1.26.2)
 

@@ -10,7 +10,7 @@ tags:
   - Worker
 ---
 
-The Rust SDK is in [Public Preview](/evaluate/development-production-features/release-stages#public-preview), and its API can change between releases.
+The Rust SDK is in [Public Preview](/evaluate/features/release-stages#public-preview), and its API can change between releases.
 The code on this page is written against `temporalio-sdk` 0.7.0.
 
 ## Create and run a Worker {/* #run-a-dev-worker */}

@@ -28,7 +28,7 @@ API. Activity Operations don't apply to [Local Activities](/local-activity) or
 
 :::note Public Preview
 
-Activity Operations are in [Public Preview](/evaluate/development-production-features/release-stages#public-preview).
+Activity Operations are in [Public Preview](/evaluate/features/release-stages#public-preview).
 Pause, Unpause, and Reset are available in Server v1.28.0+. Self-hosted UI requires v2.47.0+.
 
 Activity Operations aren't available as SDK client methods. They're operational controls designed for the CLI, UI, and

@@ -28,7 +28,7 @@ See [limitations](#public-preview-limitations) below.
 If you need to orchestrate multiple Activities, use a [Workflow](/workflows). But if you just need to
 execute a single Activity, use a Standalone Activity.
 
-Standalone Activities are Temporal’s [job queue](/evaluate/development-production-features/job-queue) -
+Standalone Activities are Temporal’s [job queue](/evaluate/features/job-queue) -
 the simplest way to run durable, retryable tasks on Temporal.
 
 <div style={{textAlign: 'center', margin: '2rem 0'}}>
@@ -64,7 +64,7 @@ Pick your SDK and follow the quickstart:
 ## Use cases
 
 Standalone Activities can be used for [durable job processing use
-cases](/evaluate/development-production-features/job-queue) such as sending an email, processing a
+cases](/evaluate/features/job-queue) such as sending an email, processing a
 webhook, syncing data, or executing a single function reliably with built-in retries and timeouts.
 
 ## Key features

@@ -0,0 +1,136 @@
+---
+id: cancellation-and-termination
+title: Cancellation and Termination
+sidebar_label: Cancellation and Termination
+description:
+  Cancellation asks a Workflow to stop and run cleanup. Termination stops it immediately without cleanup. Compare the two
+  and what each records.
+toc_max_heading_level: 4
+tags:
+  - Concepts
+  - Workflows
+  - Activities
+---
+
+Cancellation and Termination both stop a [Workflow Execution](/workflow-execution) before it finishes on its own. They
+differ in whether your Workflow code gets a say.
+
+Cancellation is cooperative. The Temporal Service delivers the request to the Workflow, and the Workflow decides what to
+do with it, which means it can release resources, compensate for completed steps, and choose its own closing status.
+Termination is forceful. The Workflow Execution is closed immediately and Workflow code never sees the request, so no
+cleanup runs.
+
+Prefer Cancellation. Reach for Termination when a Workflow can't process a Cancellation request, such as when it's
+blocked on a non-deterministic error or has no Workers to run its Tasks.
+
+## Operations summary
+
+| Operation                       | What it does                                                        | CLI                                                                     |
+| ------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------- |
+| [Cancellation](#cancellation)   | Asks the Workflow to stop, letting it run cleanup first.            | [`temporal workflow cancel`](/cli/command-reference/workflow#cancel)     |
+| [Termination](#termination)     | Closes the Workflow Execution immediately, with no cleanup.         | [`temporal workflow terminate`](/cli/command-reference/workflow#terminate) |
+
+Both operations are also available through the Web UI, the SDK Clients, and the gRPC API. Both accept a
+[List Filter](/list-filter) instead of a Workflow Id to act on matching Workflow Executions in bulk.
+
+## Cancellation
+
+### What happens when you cancel a Workflow
+
+- A [WorkflowExecutionCancelRequested](/references/events#workflowexecutioncancelrequested) Event is recorded, carrying
+  the requester's identity and the reason.
+- The Temporal Service schedules a new [Workflow Task](/tasks#workflow-task), so the Workflow can react to the request.
+- The SDK surfaces the request to Workflow code as a Cancelled Failure. See
+  [How Temporal represents failures](/encyclopedia/application-failures#failure-representation).
+- The Workflow runs whatever cleanup its implementation supports.
+- The closing status depends on what the Workflow does next.
+
+Because Cancellation is delivered as a failure, unhandled Cancellation closes the Workflow Execution as **Canceled**
+rather than Failed, recording a [WorkflowExecutionCanceled](/references/events#workflowexecutioncanceled) Event. A
+Workflow that handles the request and returns normally closes as **Completed**. Both are valid outcomes; which one you
+want is a business decision, not a technical one.
+
+Cleanup that calls Activities has to run outside the canceled scope, because a canceled scope can't schedule new work.
+Each SDK provides a mechanism for this, such as `workflow.NewDisconnectedContext` in Go. See the SDK guides below.
+
+### Cancellation and Activities
+
+Activity Cancellations are delivered to the Activity when it [Heartbeats](/encyclopedia/detecting-activity-failures#activity-heartbeat).
+This has two consequences worth planning around:
+
+- An Activity that doesn't Heartbeat can't receive a Cancellation. It runs to completion, fails, or times out.
+- Heartbeat throttling can delay delivery, so Cancellation may reach the Activity later than the request was made.
+
+If you need a long-running Activity to stop when its Workflow is canceled, it has to Heartbeat.
+
+### Cancellation across Workflow boundaries
+
+A Workflow can request Cancellation of another Workflow Execution. This records a
+[RequestCancelExternalWorkflowExecutionInitiated](/references/events#requestcancelexternalworkflowexecutioninitiated)
+Event in the requesting Workflow, followed by
+[ExternalWorkflowExecutionCancelRequested](/references/events#externalworkflowexecutioncancelrequested) once the Service
+delivers it. When the target is a [Child Workflow](/child-workflows), the parent records
+[ChildWorkflowExecutionCanceled](/references/events#childworkflowexecutioncanceled).
+
+## Termination
+
+### What happens when you terminate a Workflow
+
+- A [WorkflowExecutionTerminated](/references/events#workflowexecutionterminated) Event is recorded with the reason and
+  the requester's identity. This is the closing Event in the Workflow Execution's Event History.
+- Workflow code can't see or respond to the termination, so no cleanup runs and no compensation happens.
+- Pending Activities are not given a chance to stop cleanly.
+
+The reason is optional and defaults to the current user's name. Provide one — it's the only record of why the Workflow
+Execution was stopped.
+
+Anything a terminated Workflow would have cleaned up is left as it was: reserved inventory stays reserved, held locks
+stay held, partial writes stay written. If that matters for your use case, cancel instead, and terminate only if the
+Cancellation doesn't take effect.
+
+## Which one should you use?
+
+|                              | Cancellation                                    | Termination                        |
+| ---------------------------- | ----------------------------------------------- | ---------------------------------- |
+| **Workflow code notified?**  | Yes, as a Cancelled Failure                     | No                                 |
+| **Cleanup and compensation** | Runs, if the Workflow implements it             | Doesn't run                        |
+| **Closing status**           | Canceled, or Completed if the Workflow handles it and returns normally | Terminated    |
+| **Closing Event**            | WorkflowExecutionCanceled                       | WorkflowExecutionTerminated        |
+| **Takes effect**             | On the next Workflow Task                       | Immediately                        |
+| **Works on a stuck Workflow** | No, the Workflow has to process the request     | Yes                                |
+| **Failure type**             | Cancelled Failure                               | Terminated Failure                 |
+
+## Child Workflows
+
+A [Parent Close Policy](/parent-close-policy) decides what happens to a Child Workflow Execution when its parent reaches
+a Closed status. Two of the three values are these same operations:
+
+- **Terminate** (the default): the child is forcefully Terminated.
+- **Request Cancel**: a Cancellation request is sent to the child.
+- **Abandon**: the child isn't affected.
+
+Each child sets its own policy, so a parent can terminate some children, cancel others, and leave the rest running.
+
+## Related controls
+
+These operations also stop a Workflow Execution from progressing, but they aren't Cancellation or Termination:
+
+- **[Workflow Pause](/encyclopedia/workflow/workflow-pause)** holds a Workflow Execution in place without closing it or
+  losing state. A cancel request sent to a Paused Workflow is recorded and takes effect after the Workflow is Unpaused. A terminate request takes effect immediately.
+- **[Reset](/cli/command-reference/workflow#reset)** terminates the current Run and starts a new Run from a point you
+  choose in the Event History. Use it when a Workflow is blocked by a non-deterministic error you've since fixed.
+- **Timeouts** close a Workflow Execution as Timed Out rather than Canceled or Terminated. See
+  [Detecting Workflow failures](/encyclopedia/detecting-workflow-failures).
+
+## Handle Cancellation in your SDK
+
+Cancellation is the half of this that needs Workflow code. Termination needs none.
+
+- [.NET SDK](/develop/dotnet/workflows/cancellation)
+- [Go SDK](/develop/go/workflows/cancellation)
+- [Java SDK](/develop/java/workflows/cancellation)
+- [PHP SDK](/develop/php/workflows/cancellation)
+- [Python SDK](/develop/python/workflows/cancellation)
+- [Ruby SDK](/develop/ruby/workflows/cancellation)
+- [Rust SDK](/develop/rust/workflows/cancellation)
+- [TypeScript SDK](/develop/typescript/workflows/cancellation)
@@ -157,7 +157,7 @@ request ID.
 - Signals are accepted while Paused and processed after the Workflow is Unpaused.
 - Updates and Queries are rejected while Paused.
 - Cancel requests are recorded while Paused, but cancellation takes effect after the Workflow is Unpaused.
-- [Terminate](/evaluate/development-production-features/interrupt-workflow) requests still terminate the Workflow
+- [Terminate](/encyclopedia/workflow/cancellation-and-termination#termination) requests still terminate the Workflow
   immediately.
 - Resetting a Paused Workflow terminates the current Run and starts a new Run from the selected reset point.