Deploy with a stop condition

Rule: if the team cannot explain how it will know the release failed, it is not ready to deploy.

Before the window

• Name the release owner and the person authorized to call rollback.
• Link the exact commit, artifact digest, ticket, and change summary.
• State user impact, data changes, dependencies, expected duration, and risk level.
• Confirm tests, approvals, capacity, backups, migrations, secrets, certificates, and vendor windows.
• Write success checks and stop conditions in observable terms.
• Choose rollback, roll-forward, or feature-disable steps and test the path where practical.

During the change

• Open a timestamped release log and announce the start.
• Verify the environment and artifact before execution.
• Apply one planned stage at a time; do not hide unplanned fixes inside the release.
• Watch the user journey, errors, latency, saturation, queues, and vendor dependencies.
• Stop when a defined condition fires. Do not negotiate with the checklist mid-incident.

Verification

• Exercise the primary user journey from an external client.
• Check that writes are durable and background work drains normally.
• Compare service indicators to the pre-change baseline.
• Confirm old and new clients behave as expected where compatibility matters.
• Observe for the agreed window before declaring success.

Release record

Change:
Release owner:
Rollback authority:
Artifact / commit:
Window (UTC):
Expected user impact:

SUCCESS CHECKS
-

STOP CONDITIONS
-

ROLLBACK / ROLL-FORWARD
-

TIME | STEP | OBSERVATION | DECISION
-----|------|-------------|---------
     |      |             |

Outcome: SUCCESS / ROLLED BACK / PARTIAL
Follow-up owner and date:

Afterward

• Announce the outcome and any residual risk.
• Close temporary access, bypasses, flags, maintenance pages, and alert silences.
• Attach evidence to the release record.
• Schedule follow-up work rather than leaving a verbal promise.