Prometheus and Unleash: metrics flow both ways

If you run a platform team, you already have a metrics stack. Prometheus (or something that speaks its API, like VictoriaMetrics) is scraping your services, Grafana is drawing the dashboards, and your on-call rotation lives in those graphs. The last thing you want from a feature flag tool is another silo. Nobody wants a separate metrics store to run, another dashboard to check, and another place your data gets duplicated.

We built the Unleash and Prometheus integration around this idea. Unleash is open source, and we’d rather connect to the observability stack you already trust than ask you to replace it. That plays out in two directions:.

1. You can get Unleash’s own metrics out into your existing Prometheus and Grafana.
2. You can bring your existing Prometheus metrics into Unleash, where they drive dashboards, automate rollouts, and trigger safeguards.

Let’s walk through both.

1. Getting Unleash metrics into your stack

Every Unleash instance exposes an operational metrics endpoint at /internal-backstage/prometheus. This is a standard Prometheus text endpoint, so from your monitoring system’s point of view Unleash is just another target to scrape. You get request throughput, event-loop lag, and general service health, ready to sit next to everything else.

To start collecting, add a scrape job to your Prometheus config:

- job_name: unleash_internal_metrics
  metrics_path: /internal-backstage/prometheus
  static_configs:
    - targets: ['your-unleash-url']

If you run Unleash on Kubernetes, our Helm chart ships a configurable serviceMonitor resource for the Prometheus Operator, so you can turn on scraping without writing extra manifests.

From there, the data is yours to use however you like. Chart it in Grafana alongside your other services. Or feed a signal like event-loop lag into an autoscaler such as KEDA, which for a Node.js service is a more precise scaling signal than raw CPU.

Unleash Enterprise Edge, the caching and evaluation layer that sits between your SDKs and the Unleash server, exposes its own Prometheus-compatible metrics too. In addition to the metrics endpoint described above, Unleash Edge provides an additional option: it can push metrics upstream via Prometheus remote write, which is handy for Edge nodes running in regions that a central Prometheus can’t easily reach. You set a remote write URL and a push interval, and the Edge node writes out on its own.

None of this asks you to change how you do monitoring. Unleash produces the metrics and your stack consumes them.

2. Bringing your metrics into Unleash

This is the direction that tends to surprise people, and it’s the more interesting half.

Say you’re rolling out a new feature behind a flag. The signal that tells you whether the rollout is going well (error rate, p99 latency, a business metric) is almost always already in Prometheus. It would be a waste to re-instrument your application just so Unleash could see the same numbers. So it reads them directly.

We call these impact metrics, and they come from two sources.

• Internal metrics are recorded through an Unleash SDK and stored by us.
• External metrics are the interop story: you point Unleash at your existing Prometheus or VictoriaMetrics instance, and Unleash queries it at read time.

The external metrics data stays in your system. We don’t ingest it, copy it, or store it. When a chart is viewed or a safeguard rule is evaluated, Unleash makes a query, gets an answer, and moves on. And the load profile on your Prometheus instance looks a lot like adding another Grafana.

To set this up, check out the Unleash Admin UI under Admin settings > Impact Metrics. You enable external metrics, enter the base URL of your Prometheus instance, and click Test integration to confirm Unleash can reach it. If you’d rather manage it as config, Unleash self-hosted instances accept the EXTERNAL_PROMETHEUS_IMPACT_METRICS_API environment variable instead.

 

Once connected, your Prometheus metrics show up in the metric selector next to any internal ones, ready to chart or wire into a release.

Where this gets useful: metrics-driven rollouts

Charting metrics is fine. Acting on them automatically is the real payoff.

Unleash safeguards let a metric threshold control a rollout. You attach a safeguard to a feature flag in a specific environment, pick a metric, set a condition, and choose what happens when the condition is crossed. Because safeguards can read external metrics, the number that pauses your rollout can be the exact same error counter your SRE team already watches in Grafana.

For example, imagine you’re progressing a rollout from 25% to 50% to 100%, and you want it to stop if errors spike:

1. Metric: checkout_errors_total (already in Prometheus)
2. Aggregated by: Count
3. Condition: more than 10 in the last 15 minutes
4. Action: Pause release plan automation

Now the rollout advances on its own while the error count stays healthy, and the moment it crosses your line, automatic progression stops so you can investigate before anything gets worse. The other available action, Disable environment, turns the flag off in that environment entirely. Connected SDKs pick up the change on their next refresh, so it’s a fast, clean stop rather than a redeploy.

The whole picture

Your apps and Unleash Edge send usage data up to Unleash as normal. Prometheus scrapes Unleash (and Grafana reads Prometheus) on one side. Unleash queries Prometheus back for its Network view, impact metric charts, and safeguards on the other.

And note that the whole integration is Prometheus-compatible, not Prometheus-only, so VictoriaMetrics works too. The scrape endpoint is available in Unleash open source, while impact metrics, safeguards, and the Network dashboards are Enterprise features.

And whichever direction the data flows, it flows to and from tools you already run. That’s the point we care about most. Feature flags shouldn’t come with a walled garden. You’ve invested in Prometheus, and Unleash is built to meet it there rather than compete with it, so you get real-time control over your releases without giving up the observability stack you already trust.

Want to try it? The impact metrics docs have the full setup, or you can spin up Unleash and point it at your existing Prometheus in a few minutes.