Temporal Event

Events are created by a Temporal Service, a Temporal server paired with Persistence and Visibility stores, in response to external occurrences and Commands generated by a Workflow Execution.

Event History

An append-only log of Events that represents the full state a Workflow Execution. In other words, all of the Events in the history are written in sequential order, with each new Event following the last one written. Once an Event is written to history, it is immutable, so neither its details nor its position within the history will change.

The first Event for any Workflow Execution that was successfully launched is always WorkflowExecutionStarted. Subsequent Events will be appended as Workflow Execution progresses, although which Events those are vary based on what’s in the Workflow Definition and what happens during its execution. The Event History will end, meaning that the final Event is written, when the Workflow Execution closes. For example, if execution is successful, the final Event will be WorkflowExecutionCompleted.

Every Workflow Execution has an Event History associated with it, which represents the single source of truth for what transpired during that execution. Since the Temporal Cluster maintains this history, appending new Events based on requests from Clients and Workers, this history represents the Temporal Cluster’s perspective about what happened during Workflow Execution.

Event Histories are persisted to the database used by the Temporal Cluster, so they’re durable, and will even survive a crash of the Temporal Cluster itself. This is an important property, because Event Histories serve two key purposes in Temporal. First, they are essential for Temporal to provide its guarantee of durable execution, because Events in the history are used to reconstruct the state of a Workflow Execution following a Worker crash. Second, history information enables developers to investigate Workflow Executions. This is one of the benefits of using Temporal. Not only can you trace the steps followed during the execution of the code that’s currently running, you can also review the steps for code that ran in the past, so you’ll have insight well beyond what’s available in a traditional application.

Although The Event History is stored in the cluster’s database, you can access the history of a Workflow Execution from code that uses a Temporal SDK, from Temporal’s command-line tool, or from the Web UI.

History limit

In order to conserve space and maintain good performance, Temporal limits both the number of Events and overall size of the Event History. The Temporal Cluster begins logging warnings after 10K (10,240) events and will log additional warnings as new Events are appended to the history. If the Event History exceeds 50K (51,200) Events, the Workflow Execution may be terminated.