Logging and Cost Calculation

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 run the editor did not start — a form submission, a chat message, a webhook call — streams into the panel the same way. Its trigger row's Output (the submitted fields, the chat message) fills in a moment after the run ends, once the run's log is written: no live event carries it.

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:

Raw Agent tool arguments and results are not retained in operational logs; the log keeps tool identity, status, timing, and shape/size metadata. For tool arguments it also keeps an excerpt of at most 240 characters with secrets removed: a field whose name marks a secret (for example password, adminPassword, apiKey, clientSecret, accessToken or dbCredential) reads [REDACTED] whatever its value, and values shaped like a secret (bearer tokens, keys, signed-URL signatures) are removed wherever they appear. 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

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:

1. Integration / model pricing — the exact rate configured on the model in its integration, when present.
2. Base-model rate — a dated deployment (for example gpt-5.4-2026-03-05) reuses its base model's rate (gpt-5.4).
3. 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 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.