rollfuse

Automatic Feature Flag Rollback Driven by New Relic Metrics

How it works

A small job of yours runs your NRQL query in New Relic and sends the result to rollfuse, where a guardrail averages it over a window and aborts the rollout when it crosses your threshold.

New Relic already tells you when a deploy is causing trouble; that's what an alert condition is for. It doesn't act on it, though. Someone still has to see the notification, find the rollout that caused it and revert it. Automatic rollback with New Relic metrics closes that gap: the number behind your NRQL query reaches a rollfuse guardrail, and the guardrail aborts the rollout on its own when the number crosses a threshold.

rollfuse has no native New Relic integration. It doesn't call New Relic's API, it doesn't read your alert conditions, and an open New Relic incident doesn't trigger anything in rollfuse. What rollfuse acts on is metric values you send it. This page shows how to get them there and what happens next.

What a guardrail does with the metric

A guardrail belongs to one rollout and watches one metric definition. While the rollout is active, rollfuse periodically averages the observations it received for that metric over the guardrail's evaluation window and compares the average with your threshold. Every check is recorded with the metric value, the threshold and the action taken.

The metric definition is created once per project, with a name, a key, an aggregation type and a unit. Creating the guardrail then takes four required fields:

{
  "metric_definition_id": "<your metric definition id>",
  "comparison_operator": "gt",
  "threshold": 800,
  "evaluation_window_seconds": 600
}

That body goes to POST /v1/rollouts/{rollout_id}/guardrails. comparison_operator is one of gt, gte, lt or lte, and the window must be positive. Read it as "abort if the average of the last 10 minutes is above 800", for example a p95 latency in milliseconds.

Getting the NRQL result into rollfuse

New Relic's NerdGraph API, which is where NRQL queries run, takes a POST to https://api.newrelic.com/graphql with your user key in an API-Key header (New Relic NerdGraph introduction, accessed 2026-10-11). A rollfuse connector only sends an HTTPS GET with an Authorization: Bearer header, so it can't call NerdGraph directly. A small piece of code you run sits in between, and it can feed rollfuse in one of two ways.

Push. A scheduled job runs your NRQL query and sends each result to rollfuse:

{
  "observations": [
    { "value": 742, "occurred_at": "2026-10-11T12:00:00Z" },
    { "value": 768, "occurred_at": "2026-10-11T12:01:00Z" }
  ]
}

That body goes to POST /v1/environments/{environment_id}/metric-definitions/{metric_definition_id}/observations, authenticated with a Service Credential for that environment that has the metrics:write scope. value and occurred_at are required for each observation. If any observation in the batch is malformed, the whole batch is rejected and nothing is saved.

Pull. A small HTTPS endpoint of yours runs the query and returns the values as JSON, accepting a bearer secret. A rollfuse connector requests it on a schedule (or on demand) and records each entry as an observation. The connectors tutorial shows how to preview the mapping, create the connector and force a sync.

Either way, your New Relic key stays in your infrastructure.

What actually reverts

A breach doesn't trigger a redeploy. rollfuse aborts the rollout through the same path as a manual abort, and the flag goes back to serving its default variation to 100% of that environment. The code causing the regression is still deployed; it just stops receiving traffic while someone investigates, with the guardrail's recorded evaluation showing the value and threshold that caused the abort.

Limits worth knowing before you set this up

  • The threshold lives in rollfuse. Your NRQL alert condition and your guardrail are two separate definitions. If you tune one, tune the other.
  • No data means no abort. If no observation arrives within the window, the check is recorded as insufficient data and the rollout is not aborted. A guardrail can be set to pause the rollout after a period of missing data instead (pause_after_uncertain_seconds).
  • Guardrails are on every plan, with a cap on how many each plan allows. The cap is unlimited on Growth and Enterprise.

Your New Relic alert keeps notifying people as it does today. The guardrail is what acts on the same number. To try it on a real rollout, start with the automatic rollback tutorial.