A Datadog monitor that pages someone at 2 a.m. for a problem a rollout caused catches the regression but can't act on it. The person it paged still has to find the rollout and revert it by hand. Automatic rollback with Datadog metrics closes that gap: the same number your team watches in Datadog reaches a rollfuse guardrail, and the guardrail aborts the rollout on its own when the number crosses a threshold.
rollfuse has no native Datadog integration. It doesn't call Datadog's API, and it doesn't read your monitors. What it does is act on metric values you send it. This page shows the two ways to get a Datadog metric into rollfuse and what happens once it arrives.
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.
When the average breaches the threshold, rollfuse aborts the rollout through the same path as a manual abort. The flag goes back to serving its default variation to 100% of that environment. No redeploy is involved: the code is still deployed, it just stops receiving traffic while someone investigates.
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": 0.02,
"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 0.02", for example an error rate above 2%.
Path 1: your job pushes the metric to rollfuse
A scheduled job you already run (a cron, a worker, a step in your deploy tooling) queries Datadog with your own Datadog credentials and sends each value to rollfuse:
{
"observations": [
{ "value": 0.013, "occurred_at": "2026-10-11T12:00:00Z" },
{ "value": 0.015, "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.
This path gives you full control over how often the metric is sent, and your Datadog keys never leave your infrastructure.
Path 2: a connector pulls from an endpoint you expose
A rollfuse connector sends an HTTPS GET to a fixed URL with an Authorization: Bearer <secret> header, reads the JSON response, and records each entry as an observation. It syncs on a schedule, and you can also trigger a sync by hand.
The connector can't ask Datadog for "the last ten minutes" on its own. Datadog's timeseries query endpoint, GET /api/v1/query, takes from and to as required Unix timestamps on every call (Datadog API reference, accessed 2026-10-11), and a connector requests the same fixed URL on every sync. So the moving time window has to come from code you run: a small endpoint that queries Datadog for the recent window and returns the values as JSON. The connectors tutorial shows how to preview the mapping, create the connector and force a sync.
Limits worth knowing before you set this up
- The threshold lives in rollfuse. Your Datadog monitor 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.
The on-call engineer still gets the Datadog page if the monitor is set up that way. The difference is that the rollback doesn't wait for anyone to read it. To try it on a real rollout, start with the automatic rollback tutorial.