> 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? The current Monitoring surface puts saved-view tabs at the top. Summary cards sit above the filter row, and common actions such as Export, Edit, Alert and Pin are available from the top-right controls. The main execution list identifies the run under **Name**. ![The current Monitoring list with saved views, summary cards, filters and execution activity.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-d358318f6dfb447de64c64c79f9908f9318ab281%2Fmonitoring-list-current.png?alt=media) The 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 current filter menu also lets you narrow activity by **Activity type**, **Skills** and more advanced conditions in addition to Environment. ![The current Monitoring filter menu with Live selected and Builder available separately.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-b464d61470fd6a403ceeb107f0e924206a0db99b%2Fmonitoring-environment-filter-current.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 Messages and Tool calls separated, alongside the Transcript and Feedback tabs.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-544f64faf8a450aedb36929451f51a8b4082135c%2Factivity-overview-messages-tool-calls-current.png?alt=media) Agent session Activity also includes a **Feedback** view when feedback exists, so builders can review human outcome judgement alongside the transcript and tool activity. ### Review Agent feedback Agent work can carry feedback at two levels alongside the execution evidence: * **response feedback** — thumbs and optional comments on a specific completed Agent response; * **session outcome feedback** — a positive, negative or comment-only judgement about the piece of work as a whole. A project member can return later to edit or remove their own feedback. Authorised builders can inspect response and session feedback with the session in Activity when reviewing what happened. ![The Agent session feedback dialog in production.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fx1xLAXdsxQsFcrNsXJJY%2Fagent-session-feedback-dialog.png?alt=media) Treat feedback and technical status as different signals. A technically successful session can still receive negative feedback when the business outcome was wrong or unhelpful, while a paused or failed session can still contain useful work. Use the feedback together with the transcript, tool activity and available Skill context before deciding what should change. 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. 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. ## Related documentation * 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.