Recover from a failed deploy

When a deploy fails, capture the evidence below before changing anything. Phase names and terminal outcomes are defined in Deploy states and phases.

Capture the failure

Open the failed deploy and record:

• the deploy identifier;
• the source type and displayed source reference;
• the failed stage;
• the visible failure reason or error identifier;
• whether the App is still serving the previous release.

The timeline identifies how far the operation progressed. If promotion didn’t complete, the previous release remains live. Don’t assume the failed source received production traffic.

Correct the input

Use the failed stage to choose the next action:

• Git build or source failures: correct the repository revision, dependency, or GitHub access.
• Workspace build or source failures: inspect the captured files, .deployignore, required project files, and dependency inputs in Workspace.
• Validation failures: correct the App or service configuration named by the portal.
• Additive migration failures: inspect the migration reported by the deploy. Additive migration failures aren’t restored because the previous release accepted live writes during the attempt. The previous image remains live and compatible additive statements can remain.
• Breaking or unknown migration failures: synsmarts stops the migration Job and restores the pre-migration database before leaving maintenance mode.
• Capacity or placement failures: review Resources and the action shown by the portal.

Danger

Restore failed means recovery after a data-changing failure did not complete. Do not retry the deploy — the maintenance page stays on so a possibly half-migrated database is not served. Contact support.

Change only what the failure names — each unrelated edit creates a new deploy input and makes comparison harder.

Decide whether to redeploy

Use Redeploy when the same source choice is still correct and the failure was external or has been corrected without changing that source. For an exact Git SHA, redeploy uses that SHA. A branch or tag resolves its current tip again. A Workspace redeploy captures the current eligible files again.

Submit a new deploy when the source itself changed, such as a corrected commit, branch, dependency lockfile, migration, or App configuration.

Don’t use rollback to recover a source or release that never became live. Rollback is for returning from a serving release to a previous one.

Retry safely

After correcting the cause, return to Deploys and redeploy or submit a new source selection. Follow the new deploy identifier; the failed record remains in history.

If the failed record becomes Superseded, follow the newer operation. A superseded change can be re-applied automatically; submitting another copy while that follow-up is active creates unnecessary contention.

If the portal can’t confirm the result because you are offline or status is stale, wait for a fresh terminal state before retrying.

Verify recovery

After the new deploy completes:

1. Open the live App.
2. Verify the path or transaction that failed previously.
3. Confirm the intended Git reference or captured Workspace change.
4. Review the newer deploy’s timeline for a clean terminal outcome.

If the failure reason isn’t actionable, contact support with the App, deploy identifier, source type and displayed source reference, failed stage, and visible failure reason.