Logging and Cost Calculation
Understanding workflow logs and how execution costs are calculated in Scrydon
Scrydon provides comprehensive logging for workflow executions and automatic cost calculation for AI model usage.
Logging System
Scrydon offers two complementary logging interfaces:
Real-Time Traces (Manual Executions)
During manual workflow execution, the Traces panel at the bottom of the workflow editor updates in real time. Select a block run in the left rail to inspect its trace.
The trace viewer shows:
- A nested operation tree and duration waterfall for the block, isolated runtime, provisioning, workload, and teardown operations. A run opens at block level — expand a block to drill into its lifecycle, model, and tool operations. The path down to a failed operation expands automatically.
- For an isolated Agent turn, the model calls and tool calls appear under Executing workload while the turn runs — each model call opens as running and closes with its duration, and each sandbox tool call (
run_shell, file tools, governed actions) shows its name, duration, and outcome as soon as the runner reports it on its next model call. Only the name, timing, and outcome are streamed; the arguments and output stay in the sandbox until the turn ends. When the block completes, the runner's own timing replaces the live rows one-for-one. - A sandbox turn that is stopped by the Runtime Plane — for example because it used its whole execution budget (
exec timed out after 600s) — shows a failed Executing workload row with that reason. The turn is not re-provisioned: a fresh sandbox would replay the same work against the same budget, so the block fails there and then instead of silently repeating the turn. - A collapsed row's bar is split into coloured segments for the work it hides — model calls, tool calls, dispatch and runtime residuals — with a legend above the timeline and a tooltip giving each segment's name and duration. Expanding the row returns it to a single bar, because its children are then visible as their own rows.
- Live running, success, warning, error, and skipped status indicators; skipped blocks explain whether they were disabled, on an unselected branch, unreachable, or prevented by a halted execution
- Isolation metadata such as the selected tier, runtime class, execution ID, and pod name when a sandbox is used
- Output, input, and execution metadata sections for the selected operation, with wide payloads scrolling inside their own code block. Use the maximize control in the detail header to read a large payload full-screen; press Escape or use restore to return.
Only operational events emitted by the runtime are shown. The viewer does not expose hidden model chain-of-thought.
The live stream follows a run for as long as it keeps reporting. If a run reports nothing at all for 15 minutes, the viewer closes the stream with a polling-timeout error; re-open the run from the Logs page to see its final state.
A block that cannot be resolved from the enabled integration catalog fails before execution with an error on that block and the workflow. Check that the integration is installed, reviewed, and enabled for the organization; the run is never reported as if the block completed.
Logs Page (All Executions)
All workflow executions—whether triggered manually, via API, Chat, Schedule, or Webhook—are logged to the dedicated Logs page.
The Logs page provides:
- Comprehensive filtering by time range, status, trigger type, folder, and workflow
- Search functionality across all logs
- Live mode for real-time updates
- 7-day log retention (upgradeable for longer retention)
Log Details Sidebar
Clicking on any log entry opens a detailed sidebar view.
Block Input/Output
View the retained operational data for each block with tabs to switch between:
Output Tab shows the block's execution result:
- Structured data with JSON formatting
- Markdown rendering for AI-generated content
- Copy button for easy data extraction
Raw Agent tool arguments and results are not retained in operational logs; the log keeps tool identity, status, timing, and shape/size metadata. If a header container has an unrecognized format, Scrydon records only shape metadata rather than risking disclosure. After a security cleanup, a historical run may have no block trace while its status, cost, duration, and final output remain available.
Execution Timeline
For workflow-level logs, view detailed execution metrics:
- Start and end timestamps
- Total workflow duration
- Individual block execution times
- Performance bottleneck identification
Model Breakdown
For workflows using AI blocks, expand the Model Breakdown section to see:
- Token Usage: Input and output token counts for each model
- Cost Breakdown: Individual costs per model and operation
- Model Distribution: Which models were used and how many times
- Total Cost: Aggregate cost for the entire workflow execution
Workflow Snapshot
For any logged execution, click "View Snapshot" to see the exact workflow state at execution time.
The snapshot provides:
- Frozen canvas showing the workflow structure
- Block states and connections as they were during execution
- Click any block to see its inputs and outputs
- Useful for debugging workflows that have since been modified
Workflow snapshots are only available for executions after the enhanced logging system was introduced. Older migrated logs show a "Logged State Not Found" message.
Cost calculation
Every capability call (LLM, embedding, speech-to-text, text-to-speech, OCR, image, video) is logged by the platform with an indicative cost estimate for governance and chargeback — not an invoice. Token counts are the exact values reported by the model provider; cost is then derived from a resolved rate.
How costs are resolved
Cost is resolved in this order for every call:
- Integration / model pricing — the exact rate configured on the model in its integration, when present.
- Base-model rate — a dated deployment (for example
gpt-5.4-2026-03-05) reuses its base model's rate (gpt-5.4). - Default rate — a configurable per-capability fallback (LLM, Embeddings, STT, TTS, OCR, Image, Video) used when no catalog pricing exists.
Token-priced capabilities (LLM, embeddings) use a $ / 1M tokens rate for input and output. Unit-priced capabilities (speech, OCR, image, video) use a $ / unit rate (audio-second, page, image, …).
Cost figures are indicative estimates intended for internal governance and chargeback — not billing reconciliation. To make a figure exact, configure per-model pricing on the integration under Settings → Platform → Extensions. Already-recorded rows keep the rate that was frozen when they were logged; rate changes apply to future usage.
Cost optimization
Usage monitoring
Organisation admins can view live cost, token, and carbon-footprint breakdowns — across teams, workspaces, users, and features — from Settings → Governance → Cost Insights. The dashboard also exposes the per-model and per-capability rate configuration used by the resolution order above.
See the governance usage & cost dashboard guide for the full walkthrough of the Overview, Spend, Execution, Carbon, Chargeback, and Configuration views.