Operate and troubleshoot Velox
Use this section to monitor Velox, interpret evidence and recover failed work without creating duplicates. Always establish the system connection, test/production context, execution host, service identity and time window before changing state.
Choose the evidence path
| Observation | Start with | Then use |
|---|---|---|
| Scheduled/file-monitored work did not run | Daily operations | Flow troubleshooting or service troubleshooting |
| Flow ran but failed or produced wrong output | Execution Logs | Flow troubleshooting |
| Outbound work is queued, retrying or failed | Transport Logs | File and Transport troubleshooting |
| API caller sees an HTTP failure | API troubleshooting | Execution Logs and gateway/service evidence |
| Database, driver or folder access fails | Connection troubleshooting | Service-account and external-system evidence |
| Scripting help/signature is missing or stale | Code Library troubleshooting | Installed-version and update evidence |
| Cause is unclear or needs escalation | Diagnostics | Incident evidence checklist |
Recovery rule
Preserve the original error/status, apply one reversible correction and test one controlled item. Confirm Flow status, Transport status and every affected external destination before widening processing. A Windows service restart, Flow rerun or queue retry is an action, not proof of recovery.
Escalation evidence
Provide the Velox release, context, host/service identity, timestamps, affected module names/FIDs or log numbers, sanitised log excerpts, changes already attempted and current external-system state. Never include passwords, tokens, private keys or unredacted business payloads.
Recovery boundary
Keep automated work constrained until the cause is understood and end-to-end verification passes. Use reprocess and recover only after reconciling prior side effects.