Monitoring and Troubleshooting
Open an executable's run history and select an execution to inspect its timeline, logs, function version, profile, invocation source, transaction hashes, and available metrics. The dashboard aggregates outcomes, recent activity, and gas costs.
Cloud execution history and logs are also available through authorized management CLI and API reads. Webhook responses return a sanitized outcome and metadata; they do not include full sandbox logs.
Execution states
| State | Interpretation |
|---|---|
pending | Accepted or queued for processing. |
running | Task code is executing. |
simulating | Preview/pre-submission phase where emitted by the execution path. |
submitted | Submission is in progress or awaiting a receipt; inspect hashes. |
submitted_unknown | A known broadcast hash has no resolved receipt yet; it may still confirm. |
confirmed | The transaction was confirmed. |
failed | A task, configuration, submission, or confirmed-revert failure was recorded. |
skipped | No submission; inspect whether this was a task decision, simulation, or gate. |
The stored function ID identifies the release that ran, even after the executable changes code. Older runs without that snapshot show an unknown version instead of guessing.
Useful logs
Use ctx.logger.info, .warn, and .error. These are captured as structured execution logs. Plain console.log is not a substitute for the captured logger API. Known bound secret values are redacted, but do not log credentials or encoded variants.
Log enough context to explain decisions: the observed value, configured threshold, skip reason, and confirmation hash. Keep amounts as strings when they exceed safe numeric precision.
Investigate an outcome
| Symptom | Check |
|---|---|
| Invalid task arguments | Compare stored or webhook args with the release schema; account for JSON strings versus BigInts. |
| Permission block | Inspect resolved target/selector and profile scope, including changes from address args. |
| Repeated skips | Read the reason and simulated marker; a skip does not always mean the task evaluated successfully. |
| Profile unavailable | Finish setup, confirm the active chain, and resolve any scope update or revocation. |
| Gas failure | Check effective payer, sponsorship configuration, dBank credit, or wallet balance. |
| Sandbox failure | Inspect errors before reprovisioning; ensure code fits the timeout and memory budget. |
| Callback or storage failure after confirmation | The transaction remains confirmed; repair the checkpoint or downstream action separately. |
submitted_unknown | Reconcile the recorded hash; do not submit a duplicate merely because a wait timed out. |
Receipt timeouts with a known hash stay unresolved and can bypass onFail while awaiting reconciliation. Callbacks are not an exactly-once external notification service: use idempotent downstream operations and chain-state checks for recovery.
Metrics
Execution details may include compute time, callback time, submitted-call count, gas units, gas cost, and block metadata. The current cloud rpcCalls field is based on returned/submitted calls; it is not complete telemetry for every ctx.client request. See usage for the metering distinction.