Ship software without a red check

The two jobs nobody wants are the pre-flight checklist and the hour of watching graphs afterwards. Both are mechanical, both get skipped under pressure, and skipping them is how a bad deploy stays live overnight.

Steps

Write the pre-flight as checks, not prose

Each item must be independently verifiable, so the employee can return a hard pass or fail rather than an opinion.

Pre-flight, all must pass: - Every ticket in this release is marked done and merged - No open blocker on any included ticket - Migrations reviewed, and each has a stated rollback - Staging smoke tests green within the last 2 hours - No dependency added without a licence check - On-call is named and has acknowledged Report PASS or FAIL per item. Never mark a release good on a red check, and never soften a failure into a warning.

Trigger on merge, not on a schedule

"trigger": { "type": "event", "sources": ["release.candidate"] }

Watch the window with a heartbeat

A schedule is the wrong shape for a post-deploy watch. A heartbeat with a window checks repeatedly for a bounded period and then stops.

"trigger": { "type": "heartbeat", "interval": "5m", "window": "60m" }

Have it correlate any error spike back to the change that caused it, rather than reporting that errors rose. The correlation is the useful part.

Set the paging threshold honestly

An alerting employee that pages too often gets muted, and a muted alert is worse than no alert because you believe you are covered.

Page me only if: error rate exceeds 2x the pre-deploy baseline for more than 5 minutes, a health check fails twice consecutively, or p95 latency doubles. Everything else goes in the morning report. When you do page, lead with the change you think caused it.

Publish the notes from the tickets

Generate release notes from the actual merged tickets rather than from commit messages. Have it group by user-visible change and drop internal refactors.

Set the gate

Stays human

The deploy itself and any rollback. A rollback looks safe and is not: it can strand a migration halfway. The employee should recommend a rollback loudly and let a person execute it.

Verify

Run the pre-flight against a release you know had a problem, and confirm it fails
Deliberately leave a ticket open and confirm it will not pass
Deploy something harmless and confirm the watch window opens and closes
Confirm the release notes read like something a customer could understand
Confirm it cannot deploy or roll back on its own

When it goes wrong

It passes a release that should have failed

A check that cannot be verified was treated as passed. Require it to report UNKNOWN explicitly, and treat unknown as failure.

It pages constantly for normal variance

The baseline is wrong. Compare against the same hour on previous days, not against the hour immediately before deploy, which is often unusually quiet.

The watch never stops

A heartbeat without a window runs indefinitely. Set the window, and check it is expressed in a unit the parser accepts.