Workflow Logs Pane
The Workflow Logs Pane is accessed from the left-hand menu and also embeds into the Workflow Design Pane when a Workflow is run.
The Workflow Logs Pane presents a list of all Nodes executed including start time, duration, description and Node Properties and their values at the time they executed.
Search & Filter
Workflow Log search works backwards in time. By default the date and time controls will show the current local time and clicking Search
will find the most recent 100 logs up to that time. You can click ^ Load Earlier than ... ^
to load earlier logs and can adjust the date and time to start the search from an earlier point in time.
Once a set of logs have been loaded, there is also an on-screen Filter
. Type a term to only show rows that contain that term or click the funnel icon to toggle to Search
which will highlight matches but not hide rows that do not contain match.
Workflow Log Columns & Row Selection
The leftmost columns in the logs are standard across all Workflow Logs. The rightmost columns contain the Node Property values and the column headers change when you select a log row to show the Node Properties that are applicable to that specific Node.
Workflow Key and Instance Key
The two coloured circles on the left represent the Workflow Key and Workflow Instance Key respectively. The same color will be used to represent these Keys every time you search the logs making it easy to visually distinguish between different Workflows or different instances of the same Workflow.
Time and Duration
The timestamp columns appear below the Search and Filter UI and do not have named column headers.
These columns indicate the date and time at which the Node started to execute as well as the execution time rounded to ms, secs or mins depending on the execution time.
Hover the execution time to see the exact date/time range.
Note that the time shown is always local to the timezone of the computer being used to browse the logs.
Node
The Node columns show the name and description of the Node. If no description was set on the Node in the Workflow Design, the Node name is shown instead. Hover the Node description section to find the Node name and version that actually executed.
When a Node is considered a child step, it will be indented using bullets.
A Node execution is considered to be a child step if it follows a Trigger (e.g. Day Scheduler), an Iterator (e.g. For Each) or is a sub-Workflow Invoke.
Result
The result columns indicate whether the step completed execution successfully. For live logs, an intermediate state may be shown where the step is still executing. For completed steps, either a check or cross will be shown.
Adjacent to status column is the name of the Execution Output that fired. This is empty except for Nodes that have named Execution Outputs (e.g. The If
statement has a True
and a False
Execution Output) or the Node generated an error.
When the Node generated an error, the Error
output will fire. To see details of the error, hover or click the Error
output.
Properties
Properties differ across Nodes so the column headers will show based on the Workflow Log row that is selected.
These columns first list Input Properties and then Output Properties.
Text properties that are larger than about 100KB only be available for download. Properties that are smaller than this will either show inline or be shown in a modal when the property is clicked.
Binary properties or text properties larger than about 100KB will be shown as a download.
Flowgear normally only stores the first 5MB of a large Property and truncates Property values larger than this. When a property has been truncated, you can hover the Property value download label to see the original size.
Note that if you need to store more than 5MB of a Property value, you can force this by connecting the Property to a Variable Bar Property. We recommend using this pattern sparingly as the additional logging will reduce throughput of the Workflow.
InitData (formerly InitialisationXml) Property
The InitData
Property appears on logs for the Start
Node and contains these properties:
Site
- the key of the Site the Workflow belongs to.Environment
- the key and name of the Environment the Workflow was invoked under. Often when unexpected behavior occurs, it is because a Workflow is not running under the Environment that was expected.Workflow
- the key of the top-level Workflow that was invoked.Revision
- the revision of the Workflow that was invoked. See Revision Management for more information.InstanceId
- the unique identifier for the instance of the Workflow invoke.Username
- the email address of the user who invoked the Workflow, or in the case of an API invoke, the name of the API key that was used to invoke the Workflow.RuntimeHost
- the IP address, Site prefix (first few chars of the Site Key) and Process Id of the Runtime (backend) that was responsible for executing the WorkflowServiceHost
- the IP address and Process Id of the ServiceHost (frontend) that received the request.Mode
- indicates the Mode the Workflow was launched under.Logging
- indicates whether Low Logging is in useUrl
- the base Url when an API-bound Workflow is invoked. Querystring is excluded.TaskAcquireDelayMs
- the amount of time in milliseconds elapsed from the time the Service Host received the request to when the Runtime Host began to execute it.
PerformanceXml Property
The PerformanceXml
Property appears on logs for any Node that is routed through a DropPoint (i.e. it uses a Connection that a DropPoint has been assigned to) and contains these properties:
DropPointId
- the ID of the DropPoint that was used for the invoke.InvokeTimeMs
- the time in milliseconds that the actual invoke took at the DropPoint.
DropPoint invokes have three stages:
- Request routes from the origin Runtime via the ServiceHost to the DropPoint.
- Request is serviced at the DropPoint.
- Response is sent from the DropPoint, via the ServiceHost back to the origin Runtime.
The execution time shown in the Workflow log time column is the total time for all 3 steps. The InvokeTimeMs
is only the time for step 2.
For example, if a Node invoke takes 600ms and InvokeTimeMs
is 400ms, this means that the round trip time is 200ms and the actual invoke time is 400ms. In other words, the invoke time was slower than the round trip time.
Reviewing InvokeTimeMs
enables you to determine whether a slow invoke is due to a slow transport or a slow endpoint.