Standalone Activities Demo

SUPPORT, STABILITY, and DEPENDENCY INFO

Standalone Activities are available as a Public Preview feature in the Go, Python, and .NET SDKs, and as a Pre-release feature in the Java and TypeScript SDKs.

Standalone Activities require Temporal CLI v1.7.0 or higher and Temporal Server v1.31.0 or higher.

Standalone Activities let you run a single Activity straight from your application without writing a Workflow. Your code calls the Temporal Client, the Server durably enqueues the request for a Worker to pick up, and the result comes back through a handle that your code can wait on or check later.

Try the demo below to walk through the full flow, tweak the retry and timeout settings, and watch the SDK code and CLI command update as you go.

Configure Activity

Activity ID

Task Queue

Name

Timeout (seconds)

Timeout Type

Failure Simulation

Simulate failures

SDK Code

activityOptions := client.StartActivityOptions{
	ID:        "my-activity-id",
	TaskQueue: "my-task-queue",
	StartToCloseTimeout:    10 * time.Second,
}

handle, err := c.ExecuteActivity(ctx, activityOptions,
	helloworld.Activity, "World")
if err != nil {
	log.Fatalln("Unable to execute activity", err)
}

var result string
err = handle.Get(ctx, &result)
// result: "Hello, World!"

CLI Command

temporal activity execute \
  --type Activity \
  --activity-id my-activity-id \
  --task-queue my-task-queue \
  --start-to-close-timeout 10s \
  --input '"World"'

Execution Flow

Client

Your App

›

Server

Temporal

›

Task Queue

›

Worker

›

Activity

Function

Activity Log

Click "Execute Activity" to run the simulation

How it works

When you call client.ExecuteActivity() (or the equivalent in your SDK), the following happens:

Connect: Your application opens a connection to the Temporal Server using a Temporal Client configured with your namespace and credentials.
Schedule: The Server durably persists the Activity Task on the specified Task Queue so that the request survives Worker restarts and network interruptions.
Poll: A Worker that is polling that Task Queue picks up the Activity Task and prepares to execute it.
Execute: The Worker runs your Activity function with the provided arguments and reports the outcome back to the Server.
Return: The Server stores the result and returns it to the original caller through the ActivityHandle that was created when the Activity was scheduled.

Because the Server durably persists the Activity, it survives Worker restarts and network interruptions. If the Activity fails, the Server automatically retries it according to the Retry Policy you configure.

Standalone vs Workflow Activities

	Workflow Activity	Standalone Activity
Orchestrated by	A Workflow Definition	Your application code (via the Temporal Client)
Started with	SDK-specific (for example, `workflow.ExecuteActivity()` in Go)	SDK-specific (for example, `client.ExecuteActivity()` in Go, `client.StartActivityAsync()` in .NET)
Retry policy	Set in `ActivityOptions` inside your Workflow	Set in `StartActivityOptions` when calling the client
Visibility	Shown in the Workflow's Event History	Shown in the Activity list and count views
Use case	Multi-step orchestration with multiple Activities	Single, independent jobs like sending an email or processing a webhook

The Activity function and Worker registration are identical for both approaches, and only the execution path that triggers the Activity differs between them.

Next steps

For complete API reference and advanced usage, see the SDK-specific guides: