Lumanan watches error rates, latency, and business metrics for every rollout cohort as a release ramps from 1% to 100%. When a guardrail breaks, the ramp halts, the flag rolls back, and the evidence lands in Slack. Before the first support ticket.
| Guardrail metric | Cohort | Control | Delta | Status |
|---|---|---|---|---|
| Error rate (5xx + client) | 0.86% | 0.21% | +0.65 pp | BREACH |
| p95 latency, /checkout | 412 ms | 398 ms | +14 ms | OK |
| Checkout conversion | 3.14% | 3.19% | -0.05 pp | OK |
You already ship behind flags. But the flag does not watch itself, so the 25% cohort breaks quietly and support finds out before engineering does. Lumanan closes that loop.
A regression hitting 5% of traffic moves your global error rate by almost nothing, which is why dashboards stay green while users hit walls. Lumanan compares the rollout cohort against a matched control group, so a jump from 0.21% to 0.86% inside the cohort is loud even when the fleet-wide number barely moves.
Set thresholds per release: error rate, p95 latency, and up to five business metrics like signup or checkout conversion. On breach, Lumanan halts the ramp or rolls the flag back through your vendor's API in seconds. Prefer a human in the loop? Observe-only mode pages instead of acting.
Every halt posts a receipt: which release, which cohort, which metric breached, cohort vs. control values, and a link to the exact window in your telemetry. The 2 a.m. debate about whether to roll back becomes a 30 second read of what already happened.
No agents on your hosts, no proxy in your request path. Lumanan reads from systems you already run.
Link LaunchDarkly, Statsig, or Unleash with a scoped API key, or wrap homegrown flags with our SDK (Go, TypeScript, Python, JVM). Point Lumanan at your metrics: OpenTelemetry, Datadog, Prometheus, or CloudWatch. Read access is enough to start.
Pick the metrics that define "healthy" for this release and the thresholds that mean stop. Default templates cover error rate and p95 latency. Add the business metric your team actually argues about, then decide the action: halt, roll back, or page and wait.
Lumanan advances the flag through 1%, 5%, 25%, 50%, 100% on your schedule, holding each stage until the cohort clears its guardrails. Healthy releases reach 100% without a single glance at a dashboard. Bad ones stop in minutes, with the receipt in Slack.
One bad release that reaches 100% costs more than a year of any plan below. Prices lock in for early access teams.
Yes, and roughly a third of our design partners are in the same position. Our SDK (Go, TypeScript, Python, JVM) wraps your existing flag checks, reports cohort membership, and exposes a small control interface so Lumanan can advance, hold, or reverse a ramp. Integration is typically under 100 lines of code in one service, then you extend it at your own pace.
Aggregated metrics only: counts, rates, and latency percentiles per cohort, computed inside your telemetry stack and read through its query API. We never ingest raw logs, request payloads, or end-user PII. Flag metadata is limited to names, environments, and rollout percentages.
Data is stored encrypted in US or EU regions, your choice. Enterprise plans can run the metric collector inside your own VPC so aggregates never leave your network. A SOC 2 Type I audit is in progress, and we will publish the report when it completes rather than waving a badge before then.
Three things. Guardrails use sequential statistical tests rather than raw threshold crossings, so a single spiky minute does not trigger anything. Each metric has a minimum sample size before it can vote. And every release can start in observe-only mode, where Lumanan tells you what it would have done. Design partners typically run observe-only for two weeks, review the would-have-halted log, then turn on enforcement once they trust it.
No. Keep Datadog, Grafana, PagerDuty, all of it. Those tools answer "is production healthy?" Lumanan answers a narrower question they are bad at: "is the 25% cohort of this specific release healthy compared to everyone else?" We read from your observability stack and hand off to your incident tooling when things go wrong. We sit between them, not instead of them.
With a flag vendor and a supported metrics backend, most teams connect both and run their first observe-only rollout the same afternoon. Homegrown flags add the SDK work, usually a day or two for one service. The slowest part in practice is agreeing on thresholds, which is a conversation worth having anyway.
You cannot schedule it, but you can decide today whether it reaches 25% of your users or stops at 1%. We are onboarding a small number of early access teams each month and every one of them talks directly to the founders.