Release safety
Healthy before live
AUGUST 20, 2026 · BlackSails team · 4 min read
A failed release should stay failed
ReliabilityStarting a process is not the same as shipping a release. A runtime can launch successfully and still be unable to load configuration, reach a dependency, or answer a real HTTP request.
BlackSails treats health as the gate between a new runtime and production traffic.
01
Ready is an observed state
A deployment moves through explicit states while the runtime starts and the health endpoint is checked. Promotion happens only after the service responds within the expected window.
If it never becomes healthy, the release records the failure instead of translating an optimistic process start into a successful deployment.
02
The previous version keeps its job
A failed candidate does not deserve traffic. The last healthy release remains the production release while the new deployment stops with evidence developers can inspect.
That is less dramatic than an automatic rescue after an outage because the broken version never becomes the active version in the first place.
03
Retries need boundaries
Transient infrastructure failures can be retried, but every retry must stay tied to the same artifact and a bounded deployment attempt. Changing inputs mid-retry would make the result impossible to explain.
Reliability comes from a small number of visible states, not from an infinite loop that eventually turns green.
A release is ready when the service proves it can serve. Until then, failure is useful information—and production should remain untouched.