> For the complete documentation index, see [llms.txt](https://docs.usepylon.com/pylon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usepylon.com/pylon-docs/platform/triggers/logs-and-history.md).

# Logs & History

Advanced tooling helps you set up, debug, and iterate on your automations.

## Logs

Open a trigger and click **View Logs** to see every run of that trigger and the object it ran on. Click the object (for example, the issue number) to open it and see in its Activity Log where the trigger fired. Use the fullscreen button to expand the logs panel.

<figure><img src="https://982123570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9hXBoCTTNw5flARlUVJf%2Fuploads%2FJ1F20weLMR8n1VvWhtce%2FCleanShot%202025-06-03%20at%2021.28.09%402x.png?alt=media&amp;token=75eda448-4883-4b21-9c46-c3422e2d02f1" alt=""><figcaption></figcaption></figure>

Each row is one run:

| Column                        | Shows                                                                                      |
| ----------------------------- | ------------------------------------------------------------------------------------------ |
| Run started                   | When the run began. Click the arrow to expand the run's step-by-step log.                  |
| Issue, Account, Contact, etc. | The object the trigger ran on.                                                             |
| Status                        | The run's outcome (see below).                                                             |
| Trigger flow                  | Which flow's conditions matched.                                                           |
| Run #                         | The run's sequence number.                                                                 |
| Version                       | The [trigger version](/pylon-docs/platform/triggers/logs-and-history.md#history) that ran. |
| Attributes                    | Extra details recorded by the actions.                                                     |
| Condition Result              | For aborted runs, which conditions weren't met. Appears when any run was aborted.          |

### Run statuses

| Status      | Meaning                                                                      |
| ----------- | ---------------------------------------------------------------------------- |
| Completed   | The run finished.                                                            |
| In progress | The run is still executing.                                                  |
| Scheduled   | The run is waiting on a time delay.                                          |
| Suspended   | The run is paused mid-flow, for example while a phone call waits on routing. |
| Aborted     | The object didn't meet any flow's conditions, so no actions ran.             |
| Cancelled   | A scheduled run was removed from the time delay queue.                       |
| Failed      | The run hit an error.                                                        |

### Run details

For inbound webhook runs, the **Payload** column shows the received request body. Pylon stores up to 32 KiB of the body in the run log. Larger bodies show **Truncated**, and the stored prefix may no longer be valid JSON. This affects the log display, not the payload used to run the trigger.

Expand a run to see each step with its timestamp. Steps that failed are marked **Error:**. Some steps add links:

* **View assignee** — for team assignment steps, opens the team's assignment log for that issue.

### Filtering

Filter runs by date and status. Issue triggers can also filter by account and assignee; account triggers by account.

## History

Every time you save a trigger, Pylon records a new version. Open the trigger's menu and select **Version history** to see each version, when it was published, and who modified it. Click **Show version** to open a read-only snapshot of the trigger as it was at that version.

Use trigger history to:

1. Understand why changes in a workflow were made and who made them
2. Debug unexpected behavior by understanding the state of a trigger at a point in time — match a run's **Version** in the logs to its snapshot
3. Compare an earlier setup against the current one when you need to undo a change

<figure><img src="https://982123570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9hXBoCTTNw5flARlUVJf%2Fuploads%2FLkxx9gcurZxX4vAr6Mx7%2FCleanShot%202025-06-03%20at%2021.29.15%402x.png?alt=media&amp;token=bd5b7773-5b25-462c-97df-05b31dc95c69" alt="" width="563"><figcaption></figcaption></figure>

{% hint style="info" %}
There's no one-click restore. To go back to an earlier version, open its snapshot and reapply those settings to the trigger. While editing, use **Undo** and **Redo** in the trigger menu to step through unsaved changes.
{% endhint %}

## Time Delay Queue

Triggers can have time delays as part of their control flow. When objects are waiting on a delay, the time delay step shows how many are in the queue. Click it to open the queue and see each waiting issue, account, contact, task, or project.

* **Remove from queue** cancels the delayed run for one object.
* **Clear Queue** cancels every scheduled run for that step. This can't be undone.

Filters on a time delay are checked at the end of the delay, so an object in the queue may still be aborted.

<figure><img src="https://982123570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9hXBoCTTNw5flARlUVJf%2Fuploads%2FFtapBGrgVzqkBYPdcErT%2FCleanShot%202025-06-03%20at%2021.22.50%402x.png?alt=media&amp;token=48c4da6b-ff40-40f6-b555-83acec2388d7" alt=""><figcaption></figcaption></figure>


---

# 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.usepylon.com/pylon-docs/platform/triggers/logs-and-history.md?ask=<question>&goal=<user_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.
