To access a workflow's execution results, click the workflow's name to go
to its Workflow details page.
For details about a particular execution, on the Executions tab, click
the execution ID in the list to go to its Execution details page.
On the Summary tab, each execution has the following information:
Execution ID: the unique identifier of the workflow execution.
Execution state: indicates the workflow's end state, including the
current or final workflow step.
Execution created: when the execution was initiated.
Execution start: when the execution began running and executing steps.
Execution end: when the execution ended.
Execution duration: total time elapsed. This can be an indication of
network errors or connectivity problems.
Workflow name: the workflow name.
Workflow revision: the current revision at the time of execution.
Call log level: the level of call logging applied during the
execution. For more information, see
Call logging.
Input: the runtime arguments passed to the workflow, if any.
Output: the workflow's output. If the execution failed, includes the
exception that led to the execution's failure. In this document, see
Execution error maps.
To view the workflow execution history as a list of step entries, click the
Steps tab. For more information, see
View history of execution steps.
To view the logs for a workflow execution, click the Logs tab.
To filter the execution logs, use the Filter field at the top of the
table. For example, to display only failed execution attempts, enter
failed in the filter's text field.
gcloud
To see a full list of a workflow's executions, enter the following
command:
gcloudworkflowsexecutionslistWORKFLOW_NAME
Replace WORKFLOW_NAME with your workflow's name.
Copy the execution ID of the execution you're interested in.
To view a workflow's execution logs, enter the following command:
argument: the runtime arguments passed to the workflow, if any
endTime: when the execution ended
error: the error message thrown as a part of the exception that
resulted in the execution's failure
name: the full name of the execution, including the name of the
project, the location of the workflow, the name of the workflow, and the
execution ID
startTime: when the execution began
state: indicates the workflow's end state
status: the current or final workflow step of the execution
workflowRevisionID: the current revision at the time of the execution
Execution error maps
When a workflow throws an error during execution that isn't caught in a
try/except block, the
execution fails, and an error map (a JSON dictionary) describing the error is
returned.
Errors thrown during workflow execution contain tags to help you identify what
caused the error. For example, the error returned from a connector can have two
keys (tags and message) similar to the following:
{'tags': ['SystemError'], 'message': 'an error has occurred'}
There can be more than one tag. To check for a specific tag, you can use an
expression. For example:
${'SystemError' in e.tags}
Access error data returned as a string
Some connectors and HTTP APIs will serialize errors as strings before returning
the errors. You can use standard library functions to restore a payload to the
original error. For example, to convert an error string to a map, you can use
the json.decode
and text.encode functions:
json.decode(text.encode(ERROR_FROM_API))
Error tags
The following table describes the meaning of different error tags.
Tag
Description
AuthError
Raised when generating credentials for an HTTP request fails.
ConnectionError
Raised when a connection is successfully established with the endpoint
but there is a problem with the connection during data transfer. The
connection is terminated before a full response is received and a message
might not have been delivered to the endpoint. Retries might not be
idempotent.
ConnectionFailedError
Raised when a connection is not established with the API endpoint; for
example, due to an incorrect domain name, DNS resolution issues, or other
network problems. Retries are idempotent.
Raised when some resource limit is exhausted. When raised internally,
this type of error cannot be caught and causes immediate execution
failure.
ResponseTypeError
Raised when a long-running operation returns a response of the wrong
type.
SystemError
Raised when the interpreter finds an internal error.
TimeoutError
Raised when a system function times out at the system level.
TypeError
Raised when an operation or function is applied to an object of
incompatible type. The associated value is a string giving details about
the type mismatch.
UnhandledBranchError
Raised when one or more branches or iterations encounters an
unhandled runtime error up to a
maximum number.
ValueError
Raised when an operation or function receives an argument that has the
correct type but an incorrect value, and the situation is not described
by a more precise exception, such as an IndexError.
ZeroDivisionError
Raised when the second argument of a division or modulo operation is
zero. The associated value is a string indicating the type of the
operands and the operation.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Access workflow execution results\n\nAfter you [execute a workflow](/workflows/docs/executing-workflow), you can\naccess workflow execution results in the Google Cloud console or by using the\nGoogle Cloud CLI. \n\n### Console\n\n1. In the Google Cloud console, go to the **Workflows** page.\n\n\n [Go to Workflows](https://console.cloud.google.com/workflows)\n\n \u003cbr /\u003e\n\n2. To access a workflow's execution results, click the workflow's name to go\n to its **Workflow details** page.\n\n3. For details about a particular execution, on the **Executions** tab, click\n the execution ID in the list to go to its **Execution details** page.\n\n | **Note:** To access the **Execution details** page, you must have a role that contains the `workflows.workflows.get`, `workflows.executions.get`, and `workflows.stepEntries.list` permissions. For more information, see [Workflows roles and\n | permissions](/workflows/docs/access-control) and [Manage access](/iam/docs/granting-changing-revoking-access).\n4. On the **Summary** tab, each execution has the following information:\n\n - **Execution ID**: the unique identifier of the workflow execution.\n - **Execution state**: indicates the workflow's end state, including the current or final workflow step.\n - **Execution created**: when the execution was initiated.\n - **Execution start**: when the execution began running and executing steps.\n - **Execution end**: when the execution ended.\n - **Execution duration**: total time elapsed. This can be an indication of network errors or connectivity problems.\n - **Workflow name**: the workflow name.\n - **Workflow revision**: the current revision at the time of execution.\n - **Call log level** : the level of call logging applied during the execution. For more information, see [Call logging](/workflows/docs/log-workflow#call_logging).\n - **Input**: the runtime arguments passed to the workflow, if any.\n - **Output** : the workflow's output. If the execution failed, includes the exception that led to the execution's failure. In this document, see [Execution error maps](#execution_errors).\n5. To view the workflow execution history as a list of step entries, click the\n **Steps** tab. For more information, see\n [View history of execution steps](/workflows/docs/debug-steps).\n\n6. To view the logs for a workflow execution, click the **Logs** tab.\n\n7. To filter the execution logs, use the **Filter** field at the top of the\n table. For example, to display only failed execution attempts, enter\n `failed` in the filter's text field.\n\n### gcloud\n\n1. To see a full list of a workflow's executions, enter the following\n command:\n\n gcloud workflows executions list \u003cvar translate=\"no\"\u003eWORKFLOW_NAME\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eWORKFLOW_NAME\u003c/var\u003e with your workflow's name.\n Copy the execution ID of the execution you're interested in.\n2. To view a workflow's execution logs, enter the following command:\n\n gcloud workflows executions describe \\\n --workflow=\u003cvar translate=\"no\"\u003eWORKFLOW_NAME\u003c/var\u003e \\\n \u003cvar translate=\"no\"\u003eEXECUTION_ID\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eWORKFLOW_NAME\u003c/var\u003e: the workflow's name\n - \u003cvar translate=\"no\"\u003eEXECUTION_ID\u003c/var\u003e: the execution's unique ID\n\n This command returns output similar to the following: \n\n ```bash\n argument: 'null'\n endTime: '2022-07-19T12:40:07.070039707Z'\n error:\n context: |-\n The argument of 'in' must be a dict or an array; got: null\n in step \"checkSearchTermInInput\", routine \"main\", line: 12\n payload: \"{\"message\":\"The argument of 'in' must be a dict or an array; got: null\"\n\n ,\"tags\":[\"TypeError\"]}\"\n stackTrace:\n elements:\n - position:\n column: '26'\n length: '24'\n line: '12'\n routine: main\n step: checkSearchTermInInput\n name: projects/1051295516635/locations/us-central1/workflows/myFirstWorkflow/executions/17ffc89c-0a27-4d2f-8356-e681d949a3d3\n startTime: '2022-07-19T12:40:07.024823663Z'\n state: FAILED\n status:\n currentSteps:\n - routine: main\n step: checkSearchTermInInput\n workflowRevisionId: 000001-ac2\n ```\n The output contains the following information:\n\n \u003cbr /\u003e\n\n - `argument`: the runtime arguments passed to the workflow, if any\n - `endTime`: when the execution ended\n - `error`: the error message thrown as a part of the exception that resulted in the execution's failure\n - `name`: the full name of the execution, including the name of the project, the location of the workflow, the name of the workflow, and the execution ID\n - `startTime`: when the execution began\n - `state`: indicates the workflow's end state\n - `status`: the current or final workflow step of the execution\n - `workflowRevisionID`: the current revision at the time of the execution\n\n### Execution error maps\n\nWhen a workflow throws an error during execution that isn't caught in a\n[`try/except` block](/workflows/docs/reference/syntax/catching-errors), the\nexecution fails, and an error map (a JSON dictionary) describing the error is\nreturned.\n\nErrors thrown during workflow execution contain tags to help you identify what\ncaused the error. For example, the error returned from a connector can have two\nkeys (`tags` and `message`) similar to the following:\n\n`{'tags': ['SystemError'], 'message': 'an error has occurred'}`\n\nThere can be more than one tag. To check for a specific tag, you can use an\n[expression](/workflows/docs/reference/syntax/expressions). For example:\n\n`${'SystemError' in e.tags}`\n\n### Access error data returned as a string\n\nSome connectors and HTTP APIs will serialize errors as strings before returning\nthe errors. You can use standard library functions to restore a payload to the\noriginal error. For example, to convert an error string to a map, you can use\nthe [`json.decode`](/workflows/docs/reference/stdlib/json/decode)\nand [`text.encode`](/workflows/docs/reference/stdlib/text/encode) functions: \n\n```bash\njson.decode(text.encode(ERROR_FROM_API))\n```\n\n### Error tags\n\nThe following table describes the meaning of different error tags.\n\nYou can also [raise custom errors](/workflows/docs/reference/syntax/raising-errors)\nusing the `raise` syntax.\n\nWhat's next\n-----------\n\n- [Debugging overview](/workflows/docs/debug)\n- [Known issues for Workflows](/workflows/docs/issues)\n- [Send execution logs to Cloud Logging](/workflows/docs/log-workflow)\n- [Troubleshoot issues](/workflows/docs/troubleshooting)"]]