Get data out of Cargo and measure what ran — download a run output, export a segment or model to CSV or JSON, and pull run and batch success and error counts. Triggers: "download the results", "export this to CSV", "give me the file", "how many succeeded", "what is my error rate", "send me the enric

Cargo CLI — Analytics Measurement and export: monitoring run metrics, downloading run and batch results, and exporting segment data. See references/response shapes.md for full JSON response structures. See references/troubleshooting.md for common errors and how to fix them. See references/examples/run analytics.md for run metrics and error monitoring. See references/examples/exports.md for data export and download examples. For billing, usage metrics, and subscription: use the cargo billing skill. Bootstrap Already signed in ( cargo ai whoami returns a workspace)? Skip to the next section. Every command prints JSON to stdout; failures exit non zero with {"errorMessage": "..."} . Anything that creates a run or a batch is async — pass wait until finished or poll the matching get . When the full skill bundle is installed, [ ../cargo/references/prerequisites.md ](../cargo/references/prerequisites.md) adds the CLI version pin, token scopes, and the admin only surface. Scope — measure and export, not explain This skill answers "what happened" and "give me the data" : metrics, counts, downloads, exports. The moment the question becomes "why" — why did this run fail, why is the output wrong or empty, which root cause explains these errors, why is this play so expensive — switch to the cargo diagnostics skill; its runbooks sequence the raw surfaces into a diagnosis. The question sounds like… Load "What's the error rate?" / "How many runs failed this week?" / "Export the results / segment" this skill "Why did this run fail?" / "Run succeeded but the output looks wrong" cargo diagnostics → references/run trace.md "Why does this batch have errors? Which node keeps failing, and is it one cause or many?" cargo diagnostics → references/batch error sweep.md "Why is this play so expensive? Where do the credits go?" cargo diagnostics → references/play optimize credits.md The two skills chain naturally: analytics detects (error rate spiked, batch reports failures), diagnostics explains (18 of 20 failures share one root cause), then analytics retrieves the clean results once the cause is fixed and the runs re executed. Discover resources first Most analytics commands require UUIDs. Discover them before querying. Quick reference Picking the right command: run get metrics / run count — workflow scoped, predefined aggregations. Best when you already have a workflowUuid . orchestration query execute — ad hoc SQL across the entire workspace ( runs , batches , spans , records ). Best for cross workflow analytics, per node breakdowns, and time series. run download / run download outputs — per record output retrieval. segment download / storage query execute — storage data (Companies, Contacts, …). Workflow run metrics Aggregated metrics for workflow runs (success/error rates, credits per node). Run count Count runs matching specific criteria — useful for monitoring. Supports: statuses , batch uuid , release uuid , is finished , created after , created before , record id , record title . For cross workflow analytics or shapes that run count doesn't expose (per node failure breakdowns, p95 durations, error rate over time), use orchestration query execute — see the [Ad hoc execution analytics]( ad hoc execution analytics orchestration query) section. Ad hoc execution analytics ( orchestration query ) Run SQL against orchestration runtime tables — runs , batches , spans , records — for analytics that the canned metrics commands don't cover. Tables are referenced without a schema prefix; workspace scoping is automatic. See cargo orchestration/references/examples/queries.md for schemas and limits. Read only and capped: 30s execution time, 10 000 result rows, 10 000 000 rows scanned. Narrow with a created at / execution started at predicate to stay under the row scan cap. Downloading run results Two distinct commands — pick the right one for the job. run download — one row per run, one column per node (gzipped CSV) Returns {"url": "..."} — a signed URL to a gzipped CSV . Each row is a run: uuid , workspace uuid , workflow uuid , record id , record title , created at , finished at , status , error message , followed by one column per node slug . Each node column holds that execution's title — a truncated human readable summary, not the node's output. There is no runContext and no executions[] in this file. Treat it as a status board across many runs (which node errored, on which record), never as evidence of what a node produced — the same rule cargo diagnostics applies to title everywhere else. run download outputs — per run input + output (CSV/JSON via signed URL) This is the canonical way to get action results out of the platform. Maps to API POST /v1/orchestration/runs/download outputs . Returns {"url": "..."} — a signed URL to a CSV (default) or JSON file. One row per run: the same prefixed run metadata, plus input (the first node's resolved config) and output (the chosen node's context, defaulting to the last executed node when output node slug is omitted). To find the output node slug : cargo ai orchestration release get <release uuid → look at nodes[].slug . The terminal output node is typically named output or end . Without limit , the file covers every matching run of the workflow, so pass one when you only need a sample. Getting the full runContext for several runs You can't, in one call. The full per node context is a per run S3 object , and orchestration run get <run uuid is the only command that hydrates it — one run at a time. The two exports above are projections: download gives you node titles across many runs, download outputs gives you first node input + one node's output across many runs. For everything in between, loop run get over the UUIDs from the discovery ladder in [ ../cargo diagnostics/references/run trace.md ](../cargo diagnostics/references/run trace.md) § 0. Orchestration SQL is not an alternative here: runs and spans carry status, timing, and credits, but no node input/output columns. Downloading batch results To find the output node slug : run cargo ai orchestration release get <release uuid (get the release UUID from the batch) and look at nodes[].slug . Handling partial batch failures A batch with status: "success" can still contain individual run failures. Always inspect the batch for errors before treating results as complete. Step 1 — Check the batch summary: Step 2 — Count and download the failed runs: Step 3 — Diagnose. Working out why they failed — grouping failures by root cause, picking exemplar runs, reading runContext — is the cargo diagnostics skill's job: load ../cargo diagnostics/references/batch error sweep.md and feed it the batch UUID. Step 4 — Re run only the failed records: After the diagnosis and fixing the underlying issue (connector credentials, bad input data, rate limits): Filtering by node output slug: To download only a specific node's output from a batch (e.g. just the enrichment node, not the full run): Segment data export Filter JSON uses conjonction (not conjunction ) — this is intentional. See the cargo orchestration skill's references/filter syntax.md for the full filter syntax. IMPORTANT: segment download requires model uuid , not segment uuid . Get the modelUuid from segment list . For live paginated queries with enrichment, use segmentation segment fetch from the cargo orchestration skill. Help Every command supports help :

cargo-analytics