When a deploy fails

A failed deploy means your latest change did not go live. Your application keeps running on the previous release — nothing was taken down — so visitors are still served the last version that deployed successfully. Only the new release was held back.

What to do

1. Open the operation and read the summary. The failed deploy records where it stopped — building dependencies, running migrations, or starting the application. That tells you which part of the change to look at.
2. Check your most recent commits. Most failed deploys come from a change in the code itself: a dependency that won't install, a migration that won't run, or a build step that errors. Reproduce the failing step locally if you can.
3. Confirm your environment settings. A deploy that worked before and fails now often points at a changed setting — a new required value, a service that isn't connected, or a credential that expired.
4. Deploy again once you've made a fix. strackt will retry the whole process from a clean state. The previous release stays live until the new one succeeds.

If deploys keep failing after a clean change, reach out and we'll help you read the operation in detail.

When a rollback doesn't complete

If a new release doesn't come up cleanly, strackt keeps your previous release live — that safety net is automatic, and most of the time you never notice it. You can also roll back on purpose: from the application's Protection view, pick an earlier revision and roll back to it in seconds.

Once in a while a rollback itself can't finish. When that happens, your application stays on whichever release it was already serving — a failed rollback never leaves it in a half-switched state. What it means is simply that the version you were aiming for isn't the one that's live.

What to do:

1. Check which revision is live. The application's Protection view marks the active revision. Confirm whether it's the one you expected, so you know exactly where things stand.
2. Try the rollback again. Rollbacks are a quick switch between releases already on the server, so a second attempt usually goes straight through. Pick the revision you want and roll back once more.
3. Or deploy the version you want instead. If the revision you're after is a recent commit, deploying it fresh gets you to the same place. The current release keeps serving until the new one is live.

If a rollback keeps failing, reach out — we'll help you get the right revision live.