Rollout notes, guardrails, and what we've learned shipping carefully.
Engineering, case studies, and real decisions from people who run rollouts in production.
How Often Should a Guardrail Auto-Abort a Rollout?
A guardrail that never fires isn't conservative, it's decorative. How to read your own abort rate and calibrate thresholds that catch a real regression early.
The openfeature-provider package lets you evaluate rollfuse flags through the standard OpenFeature Go SDK, so your evaluation call sites stay vendor-neutral.
A guardrail is a metric-backed policy on a rollout: a threshold, a window, and an automatic abort on breach, so rollback doesn't need a human watching.
Blue-green gives an instant, all-or-nothing rollback by keeping the old environment warm. Feature flags give a gradual, partial rollback instead of that.
A canary controls which build serves traffic. A feature flag controls which code path runs inside one build. Different problems, often solved together.
Create a staged rollout, attach a guardrail fed by Prometheus metrics, and evaluate the target flag with go-sdk, so traffic and its safety net ship together.
Install js-sdk, construct a client, and evaluate your first flag locally in a Node.js service, with cached configuration and asynchronous exposure reporting.
Install go-sdk, construct a client, and evaluate your first flag locally in a Go service, with no network call on the hot path and a safe fallback built in.
A flag evaluation joining your existing OpenTelemetry trace is a real, shipped integration. Using an OTel metric to drive a rollout is a different story.
Feature flag platforms don't read Prometheus, and Prometheus doesn't set flags. Here's the actual shape of connecting the two, and what it really buys you.
Prometheus has the metrics a progressive rollout needs to make decisions. Making it actually drive those decisions takes one more piece than most setups have.
A canary that nobody watches isn't safer than a full deploy, it just fails slower. Here's what turns a canary stage into an automatic rollback decision.
A feature flag that only turns things on and off can't roll itself back. Automatic rollback needs a flag tied to a metric-evaluating guardrail, not a switch.
p95 latency is the standard guardrail metric for a reason: it catches broad regressions without reacting to outliers. Here's how to set one up correctly.
Error rate is the most common guardrail metric, and the easiest one to configure wrong. Here's how to define it, threshold it, and act on it automatically.
Prometheus tells you a rollout is unhealthy. It doesn't act on that by itself. Here's how to wire a PromQL result into an automatic rollback decision.
Automatic rollback deployment means a release reverts itself when a metric breaches a threshold, no human paged. Here's what has to be true for that to work.
A hypothetical walkthrough of moving checkout releases from a manual redeploy rollback to a guarded rollout, and how to measure the change on your own team.
Guardrail Templates let you define a policy shape once per project and install it onto any rollout, through the same validated path a manual guardrail uses.
Toggle-by-toggle discipline works fine until it doesn't. Here's what tends to break as a platform team's active flag count grows, and what to change first.
A latency guardrail set on p95 can watch a payments rollout the whole way to 100% while p99 quietly degrades. Here's the shape that failure mode takes.
A boolean flag and a guardrail-driven rollout solve different problems. Here's where the line actually falls, and why teams tend to hit it later than expected.