> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/reference/troubleshooting-and-support.md).

# Troubleshooting and support

Use the product evidence available for an issue, separate operator, builder and administration problems, and escalate with enough context to investigate.

Start by identifying **which layer of the operation is wrong**. A useful investigation is usually faster than retrying or changing configuration at random.

## If operational work looks wrong

For an Agent session, first inspect the session itself: the request, context used, tool activity and resulting output.

For a published Workflow app, confirm what was submitted and whether the underlying Workflow execution completed or produced a Request.

For a Request, review the evidence and question presented by that specific Workflow before responding. Request wording and available decisions are process-specific.

## If an Agent or Workflow execution failed

For a failed production Workflow, start with the failure classification and next-action guidance when it is available. It is designed to separate broad cause classes and point to the person who can most safely act next. If the classification is **unknown**, Lleverage did not have enough deterministic evidence to assign a safer cause; do not infer fault from that label alone.

Builders should then use [Monitoring](/build-and-improve/monitoring.md) and **Activity** to inspect the run and trace. Look for the failing action, relevant input/output and whether the failure is isolated or recurring. Keep the raw failure detail when escalating a case that still needs diagnosis.

A Workflow test is a real execution and can have real external side effects. Do not repeatedly test a failing write path against production data merely to collect more evidence. Test executions do not send the normal in-app Workflow-failure notification.

If a configured action has retry enabled, that is specific to that action. Lleverage does not provide a general fallback mechanism that automatically makes every failed Workflow safe to retry.

## If a connected system is involved

Check both sides of the integration:

* the relevant Connection exists in the intended Project;
* the external identity still has the required permission;
* any delegated/shared-resource permission is actually enabled for the connected identity;
* the requested resource belongs to the expected tenant/account;
* no credential or token has been copied into ordinary project content as a workaround.

See Data, connections and credentials for the authority model.

## If access or configuration looks wrong

Use [Control](/administer-and-govern/control.md) for current project configuration and membership. Product roles do not replace the organisation's own decision about who should own, operate or approve the underlying process.

## If the service itself may be unavailable

Check [Lleverage System Health](https://status.lleverage.ai/) before treating an application-wide problem as a Workflow-specific failure.

## Escalating an issue

When contacting Lleverage, include the smallest set of evidence that lets someone investigate without exposing secrets:

* organisation and Project;
* approximate time of the issue;
* session, run or Workflow identifier where available;
* what you expected and what happened instead;
* the relevant Monitoring trace or screenshot;
* whether the issue is reproducible and whether retrying would create external side effects.

Do **not** paste API keys, passwords, bearer tokens or other secret values into the report.

Formal incident-response, retention or security-evidence requirements should be verified through current support or assurance material rather than inferred from generic documentation.


---

# 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://docs.lleverage.ai/reference/troubleshooting-and-support.md?ask=<question>&goal=<endgoal>
```

`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.