Execution logs

Each execution generates logs: a chronological record of what the bot was doing. They are your main tool to understand a run and, above all, to diagnose why something failed. Since the bot usually runs unattended and without anyone watching, the logs are your window to what happened.

Verlo en directo

If you need to see the bot while it runs (not just the post-log), use Live View: shows its screen in real time during an ongoing run.

Where do the logs come from?

Hay dos fuentes:

• Messages that you issue with the Log activity in the playbook. They are the most valuable for diagnosing, because you decide what to count (“10 invoices read”, “customer without mail, skipped”). See Debugging › Log Levels.
• System messages: start and end of execution, unhandled errors and the activity/playbook in progress.

Each line identifies the playbook and the time, so you can follow the thread even if the automation invokes sub-playbooks.

View the logs

1. Enter the environment and open the Executions tab.
2. Click on the run you want to review (or its logs icon).
3. The logs appear in chronological order, from first to last.

Niveles de log

Each message has a level that indicates its importance. On the portal they are distinguished by color:

Nivel	Color	for what
debug	Gris	Fine detail for diagnosis
info	Blanco	Normal Process Events
warning	Naranja	Unexpected situations that do not stop the process
error	Rojo	Errors that affect the result

When something fails, look for red

To find the cause of a failed, go straight to the error (red) messages: they usually contain the what and where. Previous warns often give clues to the context that led to the failure.

Real-time logs

If the execution is in state running, the logs are displayed live, as the agent sends them, without you having to refresh the page. This way you can follow a long run step by step as it happens.

Take advantage of them: record with intention

The quality of your logs depends on how much you take care of them when designing. A playbook that only logs the final error is difficult to diagnose; one that leaves traces at key points is debugged in minutes:

• A info after reading data: “15 records loaded from Excel”.
• A info before a critical action: “Sending invoice form FAC-021”.
• A warn in the alternative paths: “Client 304 has no mail; sending is skipped”.
• A error within a catch: “Could not open ERP: ” + error (the error variable of a Try / Catch contains the message as text).

You see these same messages first in the Designer debug panel when testing locally, and then here in production.

Next steps

• States and lifecycle — understand why a run ended the way it did.
• Debug — output good logs from design.