Logging and monitoring reference
Distinguish customer-facing execution Monitoring from deeper platform or security telemetry when investigating an operational or technical issue.
There are now three different questions that are often called “logging”.
What did this Agent or Workflow execution do? Use Lleverage Monitoring.
Who changed configuration, and when? Use the organisation audit log where it is available, or ask the Agent to inspect recent audit events within your access.
What platform or security telemetry exists behind the service? Treat that as a separate technical or assurance question rather than assuming it is exposed in the product UI.
Customer-facing execution evidence
Monitoring is the current product surface for reviewing execution activity. Depending on the run and your access, it can expose the run record, trace, inputs, outputs, action activity, timings and errors that are available for that execution.
Use it to answer questions such as:
did the work run;
where did it stop or fail;
which actions were performed;
what inputs and outputs were involved;
whether the same pattern is recurring across runs.
Monitoring is primarily execution evidence. It should not be described as a complete security audit log, nor should technical success be treated as proof that the operational result was correct.
Organisation audit log
Lleverage also has an organisation audit log for administrative and configuration changes. It is separate from execution Monitoring: use it when you need to answer who changed what, and when, rather than what happened inside a particular Agent or Workflow run.
The Agent can query the audit log within the Project access available to the current user. Results are bounded and permission-scoped, and expose a summary of the actor, action, affected resource and time rather than raw internal metadata.
Platform and security telemetry
Incident response, forensic review, infrastructure telemetry and retention requirements can require evidence outside the customer-facing Monitoring and organisation audit-log surfaces.
Those details can change independently of the UI and may differ by the question being investigated. If an audit or incident depends on specific event coverage, fields or retention, verify that requirement against current Lleverage assurance or support material rather than inferring it from this page.
When reporting a problem
Capture the smallest useful evidence set: Project, approximate execution time, session or run identifier where available, the observed outcome, and the relevant Monitoring trace. Avoid pasting credentials or secret values into a support message.
Last updated
Was this helpful?