platform

106 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Server version check dynamic configuration key

frontend.enableServerVersionCheck (Boolean, default true) enables the Temporal server to report version information about the current server and SDK. Allowed values are true or false. This can be disabled by setting this dynamic configuration key or by setting the TEMPORAL_VERSION_CHECK_DISABLED environment variable to 1.

Visibility configuration dynamic configuration keys

frontend.visibilityMaxPageSize (Int, default 1000) sets the maximum number of Workflow Executions shown from the ListWorkflowExecutions API in one page.

Dynamic configuration can be updated without restarting the Cluster

Temporal Cluster provides dynamic configuration keys that you can update and apply to a running Cluster without restarting your services. Dynamic configuration keys are set with default values when you create your Cluster configuration, and you can override these values as you test your Cluster setup for optimal performance according to your workload requirements.

Dynamic configuration YAML format with constraints

Dynamic configuration is specified in YAML format. Values can be set globally or with constraints at the Namespace or Task Queue level. A configuration key contains an array of objects, each with a 'value' field and an optional 'constraints' object. Constraints can specify: namespace (String) for Namespace-level settings, taskQueueName (String) and taskType (optional; supported values: 'Workflow' and 'Activity') for Task Queue-level settings. When no constraints are specified, the value applies globally across the Cluster. Multiple entries for the same key allow different values for different Namespaces or Task Queues. Values set with more specific constraints take priority over values set with fewer constraints, regardless of the order in the YAML file.

Service-level RPS dynamic configuration keys

Service-level RPS (Requests Per Second) dynamic configuration keys control rate limiting for each service in the Cluster. Exceeding these limits results in ResourceExhaustedError. Frontend service: frontend.rps (Int, default 2400) sets rate limit per Frontend Service host; frontend.namespaceRPS (Int, default 2400) sets rate limit per Namespace on Frontend Service; frontend.namespaceCount (Int, default 1200) sets concurrent Task Queue polls per Namespace per Frontend host; frontend.globalNamespaceRPS (Int, default 0) sets rate limit per Namespace across Cluster (overrides per-instance limit if set); internal-frontend.globalNamespaceRPS (Int, default 0) sets rate limit per Internal-Frontend host across Cluster. History service: history.rps (Int, default 3000) sets rate limit per History Service host. Matching service: matching.rps (Int, default 1200) sets rate limit per Matching Service host.

Persistence store QPS (Queries Per Second) dynamic configuration keys

Persistence store QPS dynamic configuration keys set the maximum number of queries a service can make per second to the Persistence store. Persistence store rate limits are evaluated synchronously. If the number of queries exceeds the dynamic configuration value, you will see latencies and timeouts on your tasks. Frontend service: frontend.persistenceMaxQPS (Int, default 2000) sets max queries per second that Frontend Service host can send to Persistence store; frontend.persistenceNamespaceMaxQPS (Int, default 0) sets max queries per second per Namespace on Frontend host (if value <= 0, frontend.persistenceMaxQPS applies). History service: history.persistenceMaxQPS (Int, default 9000) sets max queries per second that History host can send to Persistence store; history.persistenceNamespaceMaxQPS (Int, default 0) sets max queries per second per Namespace for History host (if value <= 0, history.persistenceMaxQPS applies). Matching service: matching.persistenceMaxQPS (Int, default 9000) sets max queries per second that Matching Service host can send to Persistence store; matching.persistenceNamespaceMaxQPS (Int, default 0) sets max queries per second per Namespace for Matching host (if value <= 0, matching.persistenceMaxQPS applies). Worker service: worker.persistenceMaxQPS (Int, default 100) sets max queries per second that Worker Service host can send to Persistence store; worker.persistenceNamespaceMaxQPS (Int, default 0) sets max queries per second per Namespace for Worker host (if value <= 0, worker.persistenceMaxQPS applies). Visibility: system.visibilityPersistenceMaxReadQPS (Int, default 9000) sets max queries per second for Visibility database read operations; system.visibilityPersistenceMaxWriteQPS (Int, default 9000) sets max queries per second for Visibility database write operations.

Operations definition in Temporal Cloud

An operation in Temporal Cloud is anything a user does directly, or Temporal does on behalf of the user in the background that results in load on Temporal Server. Visibility queries are an exception: they hit the Server but primarily load the visibility system, so they have separate rate limits from regular OPS rate limits.

Operations per second rate limiting in Temporal Cloud

Temporal Cloud rate limits operations per second (OPS) per namespace to keep the service reliable. Each operation has an associated priority level (foreground is higher priority, background is lower priority) and a specific effect when that operation is throttled.

Cloud Run Serverless Workers Pre-release status

Cloud Run support for Temporal Serverless Workers is in Pre-release, and its APIs may change in backwards-incompatible ways. Users should create a support ticket or contact their account team for access, and sign up for updates to hear when Cloud Run reaches Public Preview.

Task Failures automatic flagging threshold

When a Workflow experiences five consecutive task failures or timeouts, it gets automatically flagged. The moment the Workflow recovers with a successful task, the flag clears.

Task Failures View enabled by default on Temporal Cloud

The Task Failures View is enabled by default for Temporal Cloud users. For self-hosted Temporal, you need to update the system.numConsecutiveWorkflowTaskProblemsToTriggerSearchAttribute dynamic config to enable it.

Enable Task Failures View in self-hosted Temporal

To enable the Task Failures View in self-hosted Temporal, update the dynamic config: temporal server start-dev --dynamic-config-value system.numConsecutiveWorkflowTaskProblemsToTriggerSearchAttribute=5

numConsecutiveWorkflowTaskProblemsToTriggerSearchAttribute configuration

The numConsecutiveWorkflowTaskProblemsToTriggerSearchAttribute is the number of consecutive Workflow Task Failures required to trigger the TemporalReportedProblems search attribute. The default value is 5. If adding this search attribute causes strain on the visibility system, consider increasing this number. To turn off the feature for a Namespace, set it to 0.

Workflow Execution History in Web UI

A Workflow Execution History is a view of the Events and Event fields within the Workflow Execution. Approximately 40 different Events can appear in a Workflow Execution's Event History.

History page execution metadata

The top of the History page lists the following execution metadata: Start Time, Close Time and Duration, Run ID, Workflow Type, Task Queue, Parent and Parent ID, SDK, State Transitions, and Billable Actions Count (Temporal Cloud only).

History Input and Results section

The Input and Results section in the History displays the function arguments and return values for debugging purposes. Results are not available until the Workflow finishes.

History tab views in Web UI

The History tab has the following views: Timeline (chronological or reverse-chronological order of events with a summary), All (view all History Events), Compact (logical grouping of Activities, Signals and Timers), and JSON (full JSON code for the workflow).

Download Event History in Web UI

The entire Workflow Execution Event History in JSON format can be downloaded from the History section.

Workflow Actions in Web UI

Workflow Executions can request a Cancellation, send a Signal or Update, or Reset and Terminate directly from the UI. You can also start a new Workflow Execution with pre-filled values using the Start Workflow Like This One button.

Workers view in Web UI

The Workers view displays the Workers currently polling on the Workflow Task Queue with a count. If no Workers are polling, an error displays.

Call Stack view in Web UI

The Call Stack view shows the captured result from the __stack_trace Query. The Query is performed when the tab is selected and works only if a Worker is running and available to return the call stack. The call stack shows each location where Workflow code is waiting.

Queries view in Web UI

The Queries view lists all Queries sent to the Workflow Execution.

Metadata view in Web UI

The Metadata view displays User Metadata including static Workflow Summary and Details and dynamic Current Details. It lists all Events with User Metadata data to give a human-readable log of what is happening in the Workflow.

Schedules page in Web UI

On Temporal Cloud and self-hosted Temporal Service Web UI, the Schedules page lists all the Schedules created on the selected Namespace. Click a Schedule to see details, such as configured frequency, start and end times, and recent and upcoming runs.

Workflow Schedule Cron string format

Temporal Workflow Schedule Cron strings follow this format: minute (0-59) hour (0-23) day of month (1-31) month (1-12) day of week (0-6, Sunday to Saturday). Example: * * * * * represents all values for each field.

Settings page visibility in Temporal Cloud

In Temporal Cloud, the Settings page is visible only to Account Owner and Global Admin roles. Click Settings to see and manage the list of users in your account and to set up integrations such as Observability and Audit logging.

Settings management in self-hosted Temporal

On a self-hosted Temporal Service, manage users, metrics, and logging in the server configuration.

Archive view in self-hosted Temporal

On a self-hosted Temporal Service, the Archive view shows Archived data of Workflow Executions on the Namespace. To see data in your self-hosted Temporal Service, you must have Archival set up and configured.

Codec Server in Web UI

The Web UI can use a Codec Server with a custom Data Converter to decode inputs and return values. The UI supports a Codec Server endpoint for details on setting the Codec Server endpoint, see Codec Server setup.

Pending Activities view in Web UI

The Pending Activities view displays a summary of recently active and/or pending Activity Executions. Clicking a pending Activity directs the user to the Pending Activities tab to view details.

Relationships view in Web UI

The Relationships view displays the full hierarchy of a Workflow Execution with all parent and child nodes displayed in a tree.

Web UI available with Temporal CLI and Temporal Cloud

The Temporal Web UI ships with every Temporal CLI release and is available with Temporal Cloud. It provides users with Workflow Execution state and metadata for debugging purposes.

Web UI open source repositories

The Temporal Web UI open source repos are temporalio/ui and temporalio/ui-server.

Web UI can be configured in own environment

The Temporal Web UI can be configured to work in your own environment. See the UI configuration reference for details.

Namespace access in Web UI

All Namespaces in a self-hosted Temporal Service or Temporal Cloud account are listed under Namespaces in the left section of the Web UI. Users can switch Namespaces from the Workflows view by selecting from the Namespace switcher at the top right corner. In Temporal Cloud, users can access only the Namespaces they have been granted access to.

Workflow listing and filtering in Web UI

The main Workflows page displays a table of all Workflow Executions within the retention period. Users can list Workflow Executions by Status, Workflow ID, Workflow Type, Start time, End time, or any other Default or Custom Search Attribute that uses List Filter. For start time and end time, users can set their preferred date and time format as UTC, Local, or Relative.

Workflow Execution details in Web UI

Selecting a Workflow Execution in the Web UI allows users to view the Workflow Execution's History, Workers, Relationships, pending Activities and Nexus Operations, Queries, and Metadata.

Saved Views feature in Web UI

Saved Views let you save and reuse frequently used visibility queries in the Temporal Web UI. Saved Views are stored locally in your browser and are available whenever you use the Temporal Web UI in that browser. Each user has their own private collection. Users can create up to 20 Saved Views.

Saved View names and character limit

Saved View names must be unique to each user and can contain a maximum of 255 characters.

Saved Views default views

By default, the Workflows page has several default Saved Views. You can apply a Saved View by clicking its name in the list to display the corresponding Workflows that match the query.

Modify Saved View temporarily in Web UI

You can modify a Saved View temporarily without changing the saved criteria by selecting the Saved View, adjusting the UI filters as needed, and the Workflows page will refresh with results of the new query without changing the Saved View. To keep temporary changes, you can click Save to replace the original Saved View, or click Edit to modify the name before saving or creating a new Saved View.

Share Saved Views as URL

You can share a Saved View as a URL by selecting the Saved View and clicking the Share button to copy the URL to the clipboard. Saved Views that use relative times will be shared with absolute time.

Task Failures View in Web UI

The Task Failures view is a pre-defined Saved View that displays Workflows that have a Workflow Task failure. These Workflows are still running, but one of their Tasks has failed or timed out. The Task Failures view displays the Workflow's ID, the Run ID, and the Workflow type. Clicking on any of the links opens the Workflow page, where you can find more information about the failed Task and remaining pending tasks, and can cancel the Workflow.

Temporal Cloud High Availability models and SLAs

Temporal Cloud offers four High Availability models: Single-Region (99.9% uptime SLA, ≤ 8 hours RTO/RPO); Same-Region Replication (99.99% uptime SLA, ≤ 20 minutes RTO, near-zero RPO); Multi-Region Replication (99.99% uptime SLA, ≤ 20 minutes RTO, near-zero RPO); Multi-Cloud Replication (99.99% uptime SLA, ≤ 20 minutes RTO, near-zero RPO). By default, Temporal Cloud provides a 99.9% contractual SLA guarantee against service errors for all namespaces. Enabling HA features for namespaces will double the consumption cost.

Identify and enable High Availability for business-critical Namespaces

Run a business-impact analysis to flag workflows where a regional outage would cause significant customer, revenue, or safety impact. For availability-sensitive Namespaces, enable High Availability features for a 99.99% contractual SLA. When choosing between same-region, multi-region, and multi-cloud replication, use multi-region or multi-cloud replication to distribute your dependencies across regions, as physically separated regions improve the fault tolerance of your application.

Applications and workers run in your compute environment

Temporal Cloud provides the capabilities of Self-Hosted Temporal as a managed service; it does not manage your applications or workers. Applications and services written using Temporal SDKs still run in your compute environment, and you have full control over how you secure your applications and services.

Give your agent this brain