—Delivery · Recovery

Rollback is specific to the execution path.

The released automatic rollback applies to the AWS ECS workflow. Axiom does not claim a universal rollback engine for every provider or resource type.

Verified ECS behavior

Before updating the service, the workflow captures the current task definition. If the new deployment does not reach ECS steady state, the workflow updates the service back to that captured definition and waits again.

01

The recovery sequence

  1. Resolve and record the task definition currently serving the target.
  2. Register or select the requested task definition and update the ECS service.
  3. Use ECS's own steady-state waiter as the deployment health boundary.
  4. On stabilization failure, restore the captured task definition.
  5. Wait for the restored service and preserve the workflow result as evidence.

02

Limits

This path restores the ECS task definition. It does not undo database migrations, external side effects, incompatible data changes, or changes made outside the workflow. Teams must keep application-level recovery steps in their own release procedure.

Trust questions

Is rollback automatic?

For the released ECS workflow, yes—when the service fails to stabilize.

What is restored?

The task definition serving the ECS service before the update.

Does it reverse a database migration?

No. Application and data recovery remain separate responsibilities.

Where does recovery run?

Inside the same OIDC-authenticated tenant workflow.

Does approval guarantee success?

No. Approval authorizes the attempt; ECS validation determines the outcome.

Are other providers covered?

No universal Azure or GCP rollback path is released.

Still blocked?

Include the failed step and error. Never send a password, token, or cloud secret.

Open support request