When to use
- Check the status of recent workflow runs at a glance
- Find failed executions to investigate further
- Monitor how often a workflow is triggered
- Get an execution ID to pass to
get-executionfor node-level debugging
Prerequisites
codikaCLI installed and authenticated- A deployed process instance (
devProcessInstanceIdorprodProcessInstanceIdinproject.json) - API key with
executions:readscope
Command
Arguments
| Argument | Description |
|---|---|
<processInstanceId> | Process instance ID (dev or prod) from project.json |
Options
| Option | Description | Default |
|---|---|---|
--workflow-id <id> | Filter results to a specific workflow | All workflows |
--failed-only | Return only failed executions | Off |
--limit <n> | Number of executions to return (1–100) | 20 |
--api-url <url> | Override API URL | — |
--api-key <key> | Override API key | — |
--profile <name> | Use a specific profile instead of the active one | — |
--json | JSON output | — |
Behavior
- Fetches recent executions from the platform API
- Returns lightweight summaries (no full result data — use
get executionfor that) - Sorted by creation time, newest first
Dev vs Prod executions
After deploying and publishing,project.json contains both instance IDs:
devProcessInstanceId to list dev executions and prodProcessInstanceId to list prod executions.
Examples
Output
codika get execution <id> for full node-level details.
Note: Zero executions is not an error — the CLI prints “No executions found.” and exits with code 0.
Error reference
| HTTP | Error | Fix |
|---|---|---|
| 401 | Invalid API key | Re-login with codika login |
| 403 | Missing scope | Create key with executions:read scope |
| 403 | No access | Process instance in different org |
| 404 | Instance not found | Check process instance ID |
Exit codes
| Code | Meaning |
|---|---|
0 | Success |
1 | API error |
2 | CLI validation error |