Inspect and troubleshoot runs - Sydekyks

Each run represents one execution. Open Run history, choose a run, and inspect its step results. Start with the first failed or unexpected step.

Read the run

Check the mission name, start time, status, duration and version. Select a step to compare its resolved input with its output. A successful step means its operation completed; it does not establish that the business result is correct.

What you see	What to check
Failed step	Error text, resolved inputs, connection and provider response
Paused run	Delay, human review or another wait step and its timeout
Missing step result	Branch path, loop item or a failure earlier in the run
Correct shape but wrong value	Mapping, hardcoded sample values or transformation
Several similar runs	Repeated events, retries or trigger polling

Fix the cause

Identify whether the problem is configuration, input data, account access or an external service.
Edit the draft or reconnect the account as appropriate.
Test with the failing sample and one normal sample.
Publish the reviewed change if live runs need the new configuration.
Inspect the next run.

Retry deliberately

A retry can repeat external side effects. Inspect which writes or sends already succeeded before retrying a failed run. Use an idempotency key or a lookup-before-create rule when the provider supports it. See retries and duplicate events.

Limits of run history

Logs can truncate inputs, offload outputs, or expire according to deployment retention. They are operational debugging records, not a complete customer-document archive or administrative audit system. Preserve required business evidence in the intended system. See limits.

The Run history view in the local development Command Center.

The Run history view in the local development Command Center.