How to Read a GHL Workflow Execution Log

GHL actually gives you three different places to look when you are trying to understand what happened to a contact: a quick workflow list, a detailed audit log, and a per-workflow execution log. Each one shows you something real and useful. None of them, on their own or even together, gives you a single ordered view of everything that happened to that contact across every workflow they touched.

That gap is not a minor inconvenience. Before Flow Inspector existed, this was how diagnosing a complex client account actually worked: manually opening each workflow’s execution log one at a time, writing down timestamps by hand, and reconstructing the sequence yourself in something like Figma or a spreadsheet. For an account with twenty or more interconnected automations, that process could take three to four hours for a single contact.

This article walks through what each of GHL’s three native views actually shows you, where each one falls short, and how to piece them together manually if you are not yet using a tool built to do it for you. For how this fits into the broader diagnostic framework, read the overview guide as well.

The fastest place to check what happened to a contact is their contact record, under Actions, then Workflows. This shows you two lists: Active workflows the contact is currently enrolled in, and Past workflows they have already gone through.

This is genuinely useful as a first glance. If you expected five automations to fire for a contact and only three are showing up in Past workflows, that tells you something is missing right away, without opening anything else.

The limitation is that this list has no timestamps and no order. You can see that a workflow fired, but not when, and not where it falls relative to the other workflows on the list. If you need to understand the sequence of events, this view cannot tell you that on its own.

The next place to look is the account’s Audit Logs, filtered down to the contact you are investigating. This gives you something Actions > Workflows does not: timestamps, and a record of specific actions like tags being added, fields being updated, and contacts being created.

In practice, this view is harder to use than it sounds, and less complete than it looks. Workflows are identified by their raw workflow ID, a long UUID string, rather than by the friendly name you gave them when you built them. Unless you have memorized which ID belongs to which workflow, you are left cross-referencing IDs against your workflow list just to figure out what you are looking at.

The timestamp you get is also more limited than it first appears. It tells you when a workflow started, not what happened after that. If a workflow has ten separate actions inside it, sending an email, waiting, updating a field, applying a tag, and so on, the Audit Log gives you one timestamp for the whole thing, not ten. You know the workflow began at a certain moment, but nothing about the sequence or timing of what happened inside it.

On top of that, the Audit Log is not guaranteed to be complete. In one real example, Actions > Workflows confirmed that five separate workflows had fired for a contact. Filtering the Audit Log for that same contact showed only four workflow related events. The fifth workflow simply was not represented. This is not a rare edge case, it happens often enough that you cannot treat the Audit Log as a complete record on its own.

Between the readability problem, the coarse timestamps, and the completeness problem, most experienced GHL operators end up avoiding the Audit Log as a primary diagnostic tool, even though it technically contains more detail than the simple workflow list.

To actually see what happened inside a specific workflow, you have to open that workflow directly and view its own execution log for that contact. This is where the real detail lives. Every individual action inside the workflow, each one timestamped down to the second, listed in the order it executed.

This is genuinely the most accurate and complete view GHL gives you natively. If you want to know exactly when a specific email sent, or exactly how long a wait step held a contact before releasing them, this is where that information exists.

The catch is that you have to do this one workflow at a time. There is no view that shows you every workflow’s execution log stitched together. If a contact touched five workflows, you are opening five separate execution logs, each with its own set of precise timestamps that only make sense in isolation from each other. Reconstructing the actual order those five workflows fired in relative to one another, and how their individual steps interleaved in time, is work you have to do yourself.

Here is the actual problem. Even if you do everything right, check Actions > Workflows for a quick overview, cross-reference the Audit Log despite its limitations, and open every individual workflow’s execution log for the real detail, you still end up with a pile of separate, disconnected views. Nothing GHL gives you natively stitches them together into one chronological picture of everything that happened to that contact.

This is not a hypothetical inconvenience. It is the exact problem that led to Flow Inspector being built in the first place. Before it existed, doing this manually for a client account with twenty or more interconnected automations meant opening twenty separate browser tabs, one execution log per automation, and physically arranging them in the order you believed they fired, jumping back and forth between tabs trying to hold the whole sequence in your head. Some of that reconstruction happened by hand in something like Figma or a spreadsheet, just to see the whole picture clearly. For a single contact, that process could easily take three to four hours.

If you are not yet using a tool that stitches this together for you, a few habits make the manual process less painful.

Start with Actions > Workflows every time. It takes seconds and immediately tells you how many workflows you are actually dealing with, which sets your expectations for how much work is ahead.

Use the Audit Log as a rough cross-check, not a primary source. It can point you toward roughly when things happened and catch something you might have missed, but do not treat it as complete or fully reliable on its own.

When you open individual execution logs, note the start time of each workflow before you dig into its steps. Having that reference point for every workflow makes it much easier to mentally sequence them relative to each other once you start comparing across tabs.

If you are doing this for a genuinely complex account with many interconnected workflows, budget real time for it. This is not a five minute task done manually, and knowing that going in helps you avoid rushing past details that matter.

GHL gives you real, useful information across three different places, but none of them, and not even all of them together, gives you a single ordered view of what happened to a contact. Knowing that gap exists, and knowing how to work within it, is the difference between confidently diagnosing an automation problem and spending hours reconstructing something that should have been visible from the start.