Overview

Every time an event fires and kicks off an action chain, UnifyApps records a trace: a structured log of the trigger, each action that ran, its input bindings, its output, its duration in milliseconds, and its final status (pass or fail). Traces are stored in the browser's Dev Tools session memory and persist across page navigations within the same session — giving you a continuous timeline even when testing multi-page flows.

Traces are distinct from the browser's Network panel. They cover action chain logic — binding resolutions, variable mutations, navigation, UI control calls — not just HTTP requests. Use traces to answer questions like: "Did my condition evaluate correctly?", "What value did this binding resolve to when the button was clicked?", or "Which action in the chain failed?"

Note: The Traces panel is only available in the Page Builder's Preview mode and is never visible to end users of your published app. Trace data is never transmitted to any server — it lives entirely in the browser session.

Opening the Traces Panel

1. Enter Preview mode: Click Preview in the builder toolbar (top-right) or press ⌘P. The app runs as a real end-user session.

2. Open Dev Tools: Press ⌘⇧D (Mac) or Ctrl+Shift+D (Windows/Linux), or click the Dev Tools button in the Preview toolbar. A resizable panel slides up from the bottom of the screen.

3. Select the Traces tab: Click Traces in the Dev Tools tab bar. The panel displays the trace list on the left and a detail view on the right. New traces appear at the top of the list in real time as you interact with the app.

Anatomy of a Trace Row

Each row in the trace list represents one complete action chain execution triggered by a single event. The row shows:

Trace Detail View

Click any trace row to open its detail view on the right side. The detail view has three sub-panels:

Action Timeline

A vertical list of every action in the chain with its own status badge, duration bar, and expand chevron. Actions are shown in execution order. Branching (conditions that lead to different paths) is shown as an indented sub-list under the condition action.

Clicking an action expands it to show:

• Input bindings — the values each bound expression resolved to at the moment the action ran

• Output / result — for API calls: HTTP status, response body; for Set Variable: the new value; for Navigate: the destination URL

• Error details — for failed actions: the error type, message, and stack summary

• Duration — precise time in milliseconds

Payload Viewer

The Payload Viewer shows a read-only JSON tree of the event payload that triggered the chain. This is the exact object available as {{ event }} inside action bindings. The viewer supports search and collapsing deep objects.

Examples of what you will find here:

• Button onClick: { nativeEvent: { type: "click", x: 320, y: 180 } }

• Table Row onClick: { rowData: { id: "ord_123", status: "pending", amount: 450 } }

• MQTT onMessage: { topic: "factory/line1/temp", payload: { value: 72.4, unit: "C" }, qos: 1 }

• Form onChange: { fieldId: "email", value: "user@example.com", prevValue: "" }

Context Snapshot

A read-only snapshot of page variable values and relevant component state at the moment the trigger fired. This is invaluable for debugging timing-dependent bugs: you can see exactly what state the app was in when the action chain ran, even if those variables have since changed.

Filtering Traces

The filter bar above the trace list provides several ways to narrow down the list:

Log to Debugger Action

Add a Log to Debugger action anywhere in an action chain to emit a custom, labeled annotation into the Traces timeline. This is the equivalent of a console.log for action chains — it adds a green marker to the trace row's action icon strip and a clearly labeled entry in the Action Timeline with whatever message or value you supply.

Tip: Add Log actions at key checkpoints in a long chain — e.g., after data transformation, before and after an API call — and bind their message to the transformed value. This makes traces self-documenting and speeds up debugging significantly compared to expanding every action manually.

Exporting Traces

Click Export (top-right of the Traces panel) to download the current filtered trace list as a .json file. The export includes:

• All visible trace rows with their full action timelines

• Payload viewer content for each trace

• Context snapshots

• App ID, page ID, and session timestamp metadata

Share the JSON file with support or teammates when reporting a bug. Support engineers can load the JSON directly into the Dev Tools Traces viewer to replay the timeline without needing access to your app.

Clearing the Trace History

Click Clear in the filter bar to erase all traces from the current session. This does not affect the running app — it only clears the Dev Tools display buffer. Traces resume recording immediately after clearing. Use Clear before testing a specific flow to isolate just those traces.

Note: The trace buffer holds the most recent 500 trace entries per session. Older entries are automatically evicted when the buffer is full. For extended testing sessions, export the traces periodically or use the time-range filter to focus on recent activity.

Tips for Effective Debugging

Tip: Diagnose a condition that always takes the wrong branch

Find the trace for the failing trigger. Expand the Condition action in the Action Timeline. The Input Bindings panel shows what value the condition expression resolved to — e.g. {{ userRole == "admin" }} resolved to false. Cross-reference with the Context Snapshot to see what userRole actually was at that moment.

Tip: Track down a slow API call

Sort the trace list by Duration (descending). The slowest action chains appear at the top. Click one and look at the per-action duration bars in the Action Timeline — the wide bar immediately identifies the bottleneck. The API Call action shows the full request/response including server-side latency vs. total round-trip time.

Tip: Verify MQTT onMessage payloads

After setting up an MQTT subscription, trigger a message from your broker. Find the resulting mqtt.<subscriptionId>.onMessage trace. Open the Payload Viewer to confirm the payload structure matches what you expected before wiring up binding expressions in the rest of the chain.

Frequently Asked Questions

Why don't I see any traces even after clicking buttons?

Traces only appear when you are in Preview mode with Dev Tools open on the Traces tab. In the builder's canvas view, action chains do not fire. If you are in Preview but still see no traces, confirm that the button or component actually has an action chain attached — open the component's Action inspector in the builder to verify. Also check that you have not applied a filter that hides the expected trace.

Do traces persist after I reload the preview?

No. Traces are stored in the browser session memory and are cleared on full page reload, browser tab close, or navigating away from the app. They do persist across in-app page navigations (a user navigating from Page A to Page B within the same preview session). Export any traces you need to keep before reloading.

Can I see traces from end users in production?

No. Traces are a developer-only tool and are never recorded in published apps running in production. For production observability — auditing which actions fired, which API calls failed, or which users encountered errors — use App Analytics (see Section 10) and structured error logging via the Log to Analytics action.

Related Pages