Standalone Activities Demo
Standalone Activities let you run a single Activity straight from your application without writing a Workflow. Your code uses the Temporal Client to send the request to the Server, 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
Failure Simulation
SDK Code
result = await client.execute_activity(
compose_greeting,
"World",
id="my-activity-id",
task_queue="my-task-queue",
start_to_close_timeout=timedelta(seconds=10),
)
# result: "Hello, World!"
CLI Command
temporal activity execute \
--type compose_greeting \
--activity-id my-activity-id \
--task-queue my-task-queue \
--start-to-close-timeout 10s \
--input '"World"'
Execution Flow
Activity Log
How it works
When you call client.execute_activity() (or the equivalent in your applicable SDK) from your
application, 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, either directly or via a handle, depending on which SDK method you use.
Standalone vs Workflow Activities
| Workflow Activity | Standalone Activity | |
|---|---|---|
| Orchestrated by | A Workflow Definition | Your application code (via the Temporal Client) |
| Started with | workflow.execute_activity() (or the equivalent in your applicable SDK) from inside a Workflow Definition | client.execute_activity() (or the equivalent in your applicable SDK) from your application code |
| Retry policy | Set when calling the Activity from inside a Workflow | Set when calling the Activity from your application |
| Visibility | Shown in the Workflow's Event History | Shown in the Standalone 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. If the Activity fails, the Server automatically retries it according to the Retry Policy you configure.
Next steps
For complete API reference and advanced usage, see the SDK-specific guides: