Run inspection

Summary#

The Run Log is the per-event history of what customers did: one row per run or action, with the customer, the tool, the module, the time and a status. It is the first screen to open when someone reports that a tool did not work, and it is the same underlying record the customer sees in their own activity history, so what you read is what they read.

Purpose#

Aggregate health tells you whether a tool is broken for everyone. It cannot tell you whether one specific person's run at 14:22 succeeded. Support questions are almost always the second kind, and answering them by asking the customer to describe what they saw is slow and unreliable.

The Run Log closes that gap. It is deliberately a log rather than an archive: it records that something happened and how it ended, not what came back. The result payload is never exposed to an admin, which keeps the console useful for diagnosis without making it a window into customers' work.

Requirements#

• An active admin session. See Getting admin access.
• MONITOR_DB bound. The activity table lives in D1 and is created on demand.
• Ideally the customer's email address and a rough time. Both narrow the search sharply.

Permissions#

Nothing on this screen mutates anything, so nothing is owner-gated and nothing is audited.

Navigation Path#

Admin console → Operations → Run Log

What a row represents#

Rows are written by several paths, all best-effort, all off the critical path so that a logging failure can never fail the action it was recording.

Each row carries a category (ai, projects, files, users, settings, auth, integrations or system), an action, a title, a module, a status and the customer's email. Timestamps are stored in milliseconds.

Article jobs are the one case where a row changes after it is written. A long generation appears as pending the moment it starts and settles into success or failed in the same row, keeping its original time. That is why a pending row from three days ago means a job that never reported back, not a job still running.

Step-by-Step Guide#

Find a specific run#

1. Select Run Log in the Operations group. The table starts empty with Search, filter by customer, or Refresh for recent runs.
2. Put the address in customer email. It is a case-insensitive substring match, so a partial address works.
3. Optionally add search tool / title / module. That searches the title, description, module, resource and email together, so a tool name, a module name or a searched domain all work.
4. Optionally set the status select: Any status, Success, Failed, Warning, Pending.
5. Press Search, or press Enter in either text field. Changing the status select searches immediately.
6. Read the header count, (<loaded> of <total>). Load more fetches the next 50 rows.

Columns are When | Customer | Tool / Action | Status. The When column is a relative time. The Tool / Action cell shows the title with the module or category beneath it.

Diagnose a failed run#

1. Find the failing row and note the exact time, the module and the customer.
2. Open Customers and load the same address. Check three things: is the account suspended, is the plan what they think it is, and have they exhausted their monthly allowance. Those three explain most reported failures without any error existing. See Customer lookup and billing.
3. Open Workflow Failures and search the address. If the failure was inside a multi-step workflow, the failing step, their input and the raw error text are there, along with whether it was a timeout. See Error log and resolution.
4. Open System Health. If the same tool shows a raised error rate in the Tool health table, or a matching row in Grouped issues, this is not one customer's problem. See Metrics and usage analytics.
5. If nothing corroborates the report, ask the customer for the exact time and the exact input. A run that left no row usually failed before it reached the worker.

Export what you found#

Press Export CSV. The file is metricvault-runs-<date>.csv with the header When (ms),Customer,Title,Module,Category,Action,Status. Only the rows currently loaded are written, so press Load more until you have the full window first. The When column is raw milliseconds and needs converting in a spreadsheet.

Limits#

The endpoint also supports filtering by category and by a start time, but the screen exposes no control for either. Use the free-text search and the customer filter instead.

Troubleshooting#

FAQs#

Does the customer see the same rows? Yes. This is the same activity record that powers their own history, so anything you can quote from the Run Log is something they can see too. See Saved Work.

Can I see what a run returned? No. The console records that the run happened, not what it produced. There is no admin path to a customer's result content.

Can I re-run something on a customer's behalf? No. The console has no run action and no impersonation. If a run needs repeating, the customer runs it. If it failed and cost them credits, refund the credits from the Customers screen instead.

Is opening the Run Log recorded anywhere? No. Reads are not audited. Only mutations are. See Audit log.

Why does a free tool show no credit cost? Zero-cost tools are described as free in the row and do not increment the monthly counters. That is expected, not a missing value.

How far back does it go? As far as the table holds. Nothing deletes rows, and there is no retention window, so the practical limit is how many pages you are willing to load.