> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/detect-investigate-and-respond-to-threats/investigate-and-respond-to-cases/automation/playbooks/build-your-playbook/configure-script-error-handling-in-a-playbook.md). # Configure script error handling in a playbook You can determine how the playbook behaves if there are script errors during execution. When defining a standard task that uses a script or a conditional task that uses an script, you can define how a playbook task continues by selecting one of the following options: * **Stop**: The playbook stops, if the task errors during execution. For example, if the task requires a manual review, you may want the playbook to stop until completion. * **Continue**: The playbook continues to execute if the task errors. For example, the playbook task requires EWS, but EWS is not required for the playbook to proceed. * **Continue on error path**: If a task errors, the playbook continues on an error path. The error path may be useful if you want to take action on an error, like clean-up, retry, etc. You may also want to handle errors in different ways. For example, in case of a quota expired error you may want to retry in 1 minute, but if you receive an internal error 500, you may want to stop the playbook. You may want to create a separate path when an analyst manually reviews the issue and research is needed outside Cortex XDR. Once an analysis is complete, you can add a task to consider escalating to a customer and, if so, generate a report that can be attached to a ticket system such as Jira or ServiceNow. Instead of a playbook waiting on manual input, which displays an error state, such as missing an argument in a script, you can add a separate path for these kinds of issues. {% hint style="info" %} Use the **`GetErrorsFromEntry`** script (part of the Common Scripts Pack) to check whether the given entry returns an error and returns an error message. For example, when using the script in a playbook, you can fetch the error message from a given task, such as a runtime error. You can then add a step in the playbook flow to send those error messages to the relevant stakeholder through Slack, email, opening a Jira ticket, etc. {% endhint %} When errors are created, they are added to context under **`task.id.error`**. How to set up error handling in your playbook 1. In a playbook, edit a task or create a task from the Task Library. 2. In the **Task Details** pane, set the **Task Type** to either Standard or Conditional.

You can set up script error handling only when running a script in a Standard task or a Conditional task. For more information about error handling settings for these tasks, see Create a standard task or Create a conditional task.

Built-in, Manual, and Ask Conditional tasks have On Error settings for number of retries and retry interval, but not Error Handling.

3. Select a script. 4. Click the **On Error** tab. 5. In the **Number of retries** field, type the number of times the tasks attempts to run before generating an error. 6. In the **Retry Interval (seconds)** field, type the wait time between retrying the task. 7. In the **Error Handling** field, select one of the following: * **Stop** * **Continue** * **Continue on error path(s)** 8. Click **Save**. 9. When adding a connector from this task to the next task, a dialog box appears which enables you to select one of the following paths: * **Standard Path**: When adding a task to this path, it executes without any exceptions. If you select the **Standard Path**, the task continues on this path and executes without exceptions. * **Error Path**: When adding a task to this path, it executes where the source task errors during execution. If you select **Error path**, if the task errors, the playbook continues with this path. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/detect-investigate-and-respond-to-threats/investigate-and-respond-to-cases/automation/playbooks/build-your-playbook/configure-script-error-handling-in-a-playbook.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.