Production guide
Promote a workflow after you have verified its code, credentials, dependencies, and failure behavior in the target execution environment.
On this page
Establish a repeatable deploymentMake writes safe to repeatVerify credentials and data boundariesVerify failures as well as successObserve and reconcileEstablish a repeatable deployment
Keep workflow source and dependency versions in version control. Run the local quickstart pattern against representative test data, then use the hosted integration path to verify the packaged artifact. Local success alone cannot validate remote packages, network access, or credentials.
Create the target environment, configure its variables and secrets deliberately, and confirm the selected workspace through /me. Use explicit timezone, environment, runtime tier, and parameters in your deployment automation. After an upload, record the returned deployment name, flow version, and code hash where provided.
Promote a tested version using deployment promotion. Reapply and inspect dependency-package and runtime settings, then verify the target schedule. Promotion does not copy credentials or make an enabled schedule safe to run against production data automatically.
Make writes safe to repeat
A request timeout can occur after a run was accepted. Poll for a known run_id before creating another run. Normal run creation does not provide a general idempotency-key contract. Use an application-generated business operation ID in your parameters and deduplicate at the destination.
Task retry, flow retry, backfill, and a duplicate inbound webhook can all repeat work. Prefer destination upserts or transactions keyed by a stable record or interval identifier. Cancellation and rollback of a deployment do not roll back external writes from previous runs.
Use bounded network timeouts and retries in provider clients. The Python local timeout cannot kill an already-running task. Make failure reporting explicit and keep retry policies from amplifying a provider outage.
Verify credentials and data boundaries
Use a scoped, expiring API key for automation and test its actual endpoints. Read the scope compatibility notes when adding schedule or workspace operations. Rotate credentials without placing them in code or command history.
Test the exact credential mechanism the task uses. A verified cloud connection or saved connector does not yet imply that a runtime receives its credentials. For restricted datasets, log counts and identifiers instead of raw records. Treat node and AI-generated code as code you must review.
Verify failures as well as success
| Exercise | Expected evidence |
|---|---|
| Valid representative input | Run succeeds and the destination contains the intended data |
| Invalid input or quality failure | Clear task error or explicit fail/quarantine route, with no unwanted write |
| Expired or insufficient credential | Actionable authorization error; no uncontrolled retry loop |
| Provider timeout or duplicate delivery | Bounded retries and no duplicated business effect |
| Failed task retry | Correct dependency handling; inspect which earlier outputs were actually reusable |
| Schedule around time changes | Expected timezone and next occurrence; no assumption of subsecond precision |
| Promotion and rollback | Intended flow version plus verified target runtime, dependencies, and configuration |
Observe and reconcile
Record application operation IDs alongside Dagy run IDs. Poll run status and logs, inspect usage, and configure supported success/failure notifications. Treat webhooks as signals to reconcile with run state, because delivery is best effort.
Set application-side alerts for a run remaining queued or running longer than expected. Stored SLA thresholds and retry alert labels do not currently provide automatic SLA or retry notifications. Review limits before setting polling frequency or scheduling a large backfill.
For an unresolved issue, collect the API method/path, status, sanitized response, run/deployment ID, workspace/environment, SDK version, and timestamp. Send credentials and sensitive payloads through neither logs nor support messages. The troubleshooting guide maps common symptoms to the next useful check.