ConnXL Docs

Operate

Logs & exports

Every function call an agent runs is reported back as a usage event — never the data, only the metadata. The dashboard rolls those events into analytics you can read on screen or download as a spreadsheet. This page also covers the separate agent process-log viewer used to diagnose a broken function.

7 min read

Two different things share the name 'Logs'

Usage analytics (below) is the Telemetry/Logs page: aggregated call counts, latency, and top users over a rolling window — for understanding how your add-in is used. The agent process logs further down this page is a different, live tail of the agent's own debug/info/error output — for diagnosing why one function call just failed. If you're chasing a broken function right now, skip to that section.

What the analytics show

The Telemetry and Logs pages cover a rolling window (30 days by default, adjustable):

  • Daily usage — calls and errors per day, and the data volume moved, so you can see busy periods at a glance.
  • Top functions — the most-called functions, ranked by execution count, with error counts.
  • Slowest functions — ranked by latency, to point you at what to optimize.
  • Top users — the busiest end-users, shown as domain · hash (for example acme.com · 7a3f…).

Raw emails never reach the dashboard

A user's identity is reduced to their email domain plus a one-way SHA-256 hash before it leaves the agent. You can tell two users apart and see their domain, but the dashboard never stores or shows a raw address.

Exporting

There are two ways to take the data out of the dashboard.

  • Quick .xlsx export — downloads the current analytics window as a workbook with three sheets: Daily usage, Top functions, and Top users. Generated on the spot.
  • Async log export — for a larger pull, request an export and the backend builds it in the background. It appears in the exports list when it's ready, and you download the finished .xlsx from there.

Analytics are per add-in

What you see is filtered to the add-ins in your organization and the window you pick, so an export is a faithful snapshot of exactly what's on screen.

Agent process logs

This is the other "Logs" — a live diagnostics panel on the environment's Agent page, not the analytics above. Where usage analytics tells you how much your add-in is being used, this tells you what the agent itself was doing, line by line, right before something broke.

  • Fetch-on-demand, not a persisted history. Clicking the panel sends the agent a get_logs command over its control channel, and the agent answers with up to 500 of its most recent lines, held in an in-memory ring buffer — it's a tail of right now, not a searchable archive going back weeks.
  • Level filters — chip toggles for debug / info / error narrow the fetched lines client-side.
  • Scrubbed before it ever leaves the agent. Sensitive values (secrets, connection strings, tokens) are stripped inside the agent as lines enter the ring buffer — the dashboard only ever displays already-scrubbed text, it never redacts on the way in.
  • Which replica answered — if the environment runs several replicas, an arbitrary live one answers and a footnote names its hostname, so you know which process's logs you're looking at.
  • Requires the environment's agent to be online (the same gate as sending any other command), and is admin-gated like the rest of the runtime controls.

Use this when a specific function just failed

The usage analytics tell you a function is erroring; the agent process logs tell you why — the actual exception or connection error the agent hit while running it. See Troubleshooting for the rest of the "how do I fix X" playbook.

On this page