> 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/build-and-improve/monitoring.md). # Monitoring Inspect what Lleverage actually executed, where work stopped and whether the business result followed from the run. Use Monitoring when the question is not "what is configured?" but **"what actually happened?"** For example: did the supplier-follow-up Workflow run, where did the order process fail, which step produced the wrong value, or did a technically successful execution actually create the expected business result? ## What Monitoring helps establish Use it to answer questions such as: * Did the Workflow or Agent run? * Where did it stop, wait or fail? * What inputs, outputs and tool activity were involved? * Is the issue isolated or recurring across runs? * Did the downstream business post-condition actually happen? ![Monitoring with saved views, run/error trends and recent execution activity.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FTob1folNpn7CZkWwHul6%2Fmonitoring-list.png?alt=media) The current Monitoring list defaults to the **Live** environment, so Builder executions are hidden until you change the Environment filter. This keeps normal operational review focused on live runs while still allowing builders to include their test activity when needed. ![The Monitoring Environment filter with Live selected and Builder available separately.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FFv9lcUfMpzQ9w6o9NvBU%2Fmonitoring-environment-filter.png?alt=media) Monitoring is evidence about execution, not automatic proof that the business outcome was correct. A technically successful run can still produce the wrong operational result. ## Build operational dashboards from Data Tables A Monitoring saved view can also surface live operational data from **Data Tables**. This is useful when the question is not only whether work ran, but whether an operational measure is moving in the right direction. When configuring a Data Table chart, builders can choose the chart type and fields, split a chart into series, configure per-series labels and colours, select a date column, bucket dates by day or week, and choose whether the axis starts at zero or at the lowest observed value. Depending on the widget, the dashboard can also emphasise thresholds, compare a statistic with the previous period, or highlight table rows that cross a limit. ![Data Table chart configuration in a live production Monitoring dashboard.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FJVxOlsGgTPfsTIFCnRCr%2Fdata-table-chart-config.png?alt=media) Because the widgets read from the underlying Data Table, the dashboard updates as new records land. Use a saved view when the layout and filters should represent a repeatable operational lens, such as quality, throughput or exceptions for a specific process. ## Activity and traces Activity gives you the execution record for Workflows and Agent work. Open an individual trace to inspect the path through a run, then compare patterns across runs when deciding what to improve. For Agent sessions, the Overview separates **Messages** from **Tool calls**. **Messages** counts conversational turns with visible user or assistant text; tool-only Agent steps are counted under **Tool calls** instead of inflating the message count. This makes the Overview easier to compare with the conversation shown in the Transcript. ![An Agent Activity session Overview with conversational Messages and Tool calls shown separately.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FC8utYM0DLUCOgAp79s9k%2Factivity-overview-messages-tool-calls.png?alt=media) Current Workflow traces can lead with business **Metrics** emitted during the run, alongside the run selector and controls such as **Open in Builder** and **Share Session**. Expanding the action record shows the individual actions and their timings. Together these help distinguish a slow or failing execution step from a business-level result that simply needs different logic or inputs. ![An opened execution trace showing run metrics and the controls for opening the run in Builder or sharing the session.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FEWgLZxDQTXV2Cjwn9jEe%2Fmonitoring-trace-metrics.png?alt=media) If the issue points to a repeatable execution-path problem, go to Automate. If the same incorrect instruction or missing context recurs, go to Intelligence. ## Requests are another form of operational evidence Repeated Requests, corrections and manual interventions can reveal missing data or rules even when the Workflow itself does not fail technically. ## Alerts Alerts can surface conditions that need attention without requiring someone to watch Monitoring continuously. Keep them focused on conditions that lead to a real action. ## Where to go next * Change repeatable execution → Automate * Improve reusable methods or context → Intelligence * Investigate human exception patterns → Requests * Configure runtime authority or system access → Control --- # 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/build-and-improve/monitoring.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.