Driving a Progressive Rollout From a Go Service

A progressive rollout is a Rollout resource attached to an EnvironmentFlagConfig: a target variation and a sequence of stages, each with a target percentage and an activation time. The API advances traffic on schedule; a guardrail attached to the rollout can abort it automatically if a metric breaches. None of that requires touching your service's code path beyond one thing: evaluating the flag go-sdk already caches locally.

Create the rollout

POST /v1/environment-flag-configs/{environment_flag_config_id}/rollouts
{
  "target_variation_id": "...",
  "stages": [
    { "target_percentage": 5,   "activate_at": "2026-09-01T14:00:00Z" },
    { "target_percentage": 25,  "activate_at": "2026-09-01T14:10:00Z" },
    { "target_percentage": 50,  "activate_at": "2026-09-01T14:25:00Z" },
    { "target_percentage": 100, "activate_at": "2026-09-01T14:40:00Z" }
  ]
}

Creating a rollout requires a signed-in member who holds the rollouts:manage permission, either in the console or through the API with that member's session; a service credential can't do it. (The github-action repo does something different: it evaluates a flag inside a workflow and fails the step when the variation doesn't match, which is useful for gating a deploy step.) Stage percentages must strictly increase and the final stage must land at exactly 100; the API rejects a malformed sequence up front rather than letting a rollout stall partway.

Attach a guardrail

POST /v1/rollouts/{rollout_id}/guardrails
{
  "metric_definition_id": "...",
  "comparison_operator": "gt",
  "threshold": 0.4,
  "evaluation_window_seconds": 300
}

The metric definition holds no query: the p95 values reach rollfuse as observations, pushed through the API or pulled by a connector, as how to monitor a progressive rollout explains. The guardrail is evaluated periodically while the rollout runs, not once per stage, averaging the observations in its window: a regression that only shows up once traffic crosses from 5% to 25% is still caught. If the average goes above the threshold, the rollout aborts automatically and the flag goes back to serving its default variation to 100% of the environment; nothing in your Go service needs to react to that, since the next Evaluate call simply reads the reverted Configuration.

Evaluate the target flag

result, err := client.Evaluate(subjectKey, "checkout-redesign",
    rollfuse.WithFallback(false), // used only if no Configuration is cached yet
)
if err != nil {
    // handle error (ErrConfigNotReady, ErrFlagNotFound)
}

var enabled bool
_ = json.Unmarshal(result.Value, &enabled)

if enabled {
    // this request landed in the rollout's active percentage
}

go-sdk doesn't know or care that a rollout is in progress; it evaluates whatever the current cached Configuration says, and the rollout's job is to change what that Configuration says as stages advance. That's the same Evaluate call your service already makes for any flag; a progressive rollout changes the traffic shape behind it, not the call site.

Watching it happen

The console shows the rollout's stage progress and its guardrails, refreshes on its own, and keeps each guardrail's evaluation history. To feed the guardrail from metrics you already collect, see how to monitor a progressive rollout for getting Prometheus values into rollfuse, pushed through the API or pulled by a connector.