Skip to main content

​
When to use

  • Debug a workflow execution that failed or returned unexpected results
  • Inspect node-level input/output for a specific execution
  • Fetch sub-workflow execution details recursively
  • Analyze execution timing and identify bottlenecks

​
Prerequisites

  • codika CLI installed and authenticated
  • A deployed and triggered workflow
  • An execution ID (from the trigger command response)

​
Typical debugging flow

# 1. Deploy
codika deploy use-case .

# 2. Trigger and get execution ID
codika trigger main-workflow --poll --payload-file - <<'EOF'
{"text": "test"}
EOF

# 3. Debug with full details
codika get execution <executionId> --deep --slim

​
Command

codika get execution <executionId> [options]

​
Arguments

ArgumentDescription
<executionId>Codika execution ID (from trigger response)

​
Options

OptionDescriptionDefault
--process-instance-id <id>Explicit process instance IDAuto-resolved from project.json
--project-file <path>Path to custom project file (e.g., project-client-a.json)project.json
--path <path>Path to use case folder with project.jsonCurrent directory
--deepRecursively fetch sub-workflow executionsOff
--slimStrip noise (pairedItem, workflowData) for readabilityOff
-o, --output <path>Save to file instead of stdoutstdout
--api-url <url>Override API URL—
--api-key <key>Override API key—
--profile <name>Use a specific profile instead of the active one—
--jsonJSON output—
For most debugging, use both flags together: 
codika get execution <id> --deep --slim
  • --deep gives you the complete execution tree including sub-workflows
  • --slim removes noisy metadata for cleaner, more readable output

​
Process instance ID resolution

  1. --process-instance-id flag
  2. devProcessInstanceId in --project-file (if provided)
  3. devProcessInstanceId in project.json at --path
  4. devProcessInstanceId in project.json in current directory

​
Deep mode

When --deep is used, the CLI recursively fetches sub-workflow executions and attaches them as _subExecutions on the parent node that triggered them. This gives you the complete execution tree.

​
How it works

  1. Fetches the main execution
  2. Identifies nodes that called sub-workflows (Execute Workflow nodes)
  3. Recursively fetches each sub-workflow execution
  4. Attaches results as _subExecutions on the parent node
This builds a complete execution tree for multi-workflow use cases.

​
Slim mode

Strips noisy fields for cleaner output:
  • Removes pairedItem from all nodes
  • Removes workflowData from execution metadata
Best used with --deep for debugging: --deep --slim

​
Examples

# Basic execution details
codika get execution exec_abc123

# Full recursive details, clean output
codika get execution exec_abc123 --deep --slim

# Save to file for analysis
codika get execution exec_abc123 --deep --slim -o debug.json

# Explicit process instance ID
codika get execution exec_abc123 --process-instance-id pi_def456

# From a specific use case directory
codika get execution exec_abc123 --path ./my-use-case

​
Output

Execution: exec_abc123
Status:    success
Duration:  12.3s
n8n ID:    n8n_xyz789
Nodes:     8

  ✓ Webhook Trigger        (0.1s)
  ✓ Codika Init            (0.3s)
  ✓ Fetch Data             (2.1s)
  ✓ Process Results         (0.5s)
  ✓ Call Sub-Workflow       (8.2s)
    └── Sub-workflow execution:
        ✓ Execute Workflow Trigger  (0.0s)
        ✓ Transform Data           (0.4s)
        ✓ Generate PDF             (7.5s)
        ✓ Upload File              (0.3s)
  ✓ IF Success             (0.0s)
  ✓ Codika Submit Result   (0.1s)

​
Exit codes

CodeMeaning
0Success
1API error or execution not found