Every guardrail we ship starts as a policy shape: a comparison operator, a threshold, an evaluation window, and optionally a promote-after-healthy, pause-after-uncertain, or resume-cool-down duration. Until now, defining that shape was a per-rollout act. Copy the same p95 threshold into every new rollout on the same service, by hand.
Guardrail Templates change that. Define the shape once per project, then install it onto any rollout in that project.
How it works
A GuardrailTemplate carries the same tunable fields a manually-authored guardrail does, validated with the exact same rules. What it deliberately doesn't carry is a reference to a specific metric definition or rollout. Those get supplied at install time, so one template (say, "checkout p95, 500ms, 5-minute window") can back a guardrail on a dozen different rollouts across a project, each pointed at that rollout's own metric.
Installing a template produces a guardrail through the identical creation path a manually-authored one goes through: no shortcut, no bypass of ownership or threshold validation. It's the same object underneath; the template is just where the policy shape now lives so it doesn't have to be retyped.
Why this matters
If your team runs the same latency or error-rate threshold across every service in a project, which most teams do, since a shared SLO usually implies a shared guardrail policy, a template turns "remember to set the threshold correctly on every new rollout" into "install the template." A threshold that needs recalibrating (see why a guardrail that never fires isn't conservative) now gets updated in one place instead of hunted down across every rollout that copied it.
Guardrail Templates are available today on every plan.