Know what's breaking your budget before it's gone.
Veirox turns your service-level objectives into continuously computed error budgets and multi-window burn-rate alerts — reading your own Prometheus through an outbound-only connector, so your metrics never leave your network. Budget risk, not alert volume, decides what you work on today.
The problem
No shared unit
Forty firing alerts and one slow-burning outage look identical in a channel full of noise. Alert count tells you nothing about how close a service actually is to breaching its commitment.
No data-backed answer
Without a target and a budget, that question gets answered by gut feel and who's shouting loudest — not by how much runway is actually left before something breaks a real commitment.
Reactive by default
Reliability work competes with feature work for attention. Without a number that says "this service has 6% of its budget left," it loses every time — until it becomes an incident.
What Veirox does
Declare a target for availability, latency, correctness, freshness, or throughput on any service in your inventory. Each objective FKs to a real service and a real metric source — there's no separate catalog to keep in sync.
Every objective is re-evaluated on a fixed cycle: current SLI, remaining budget, and a forecast of when it runs out at the current burn rate. A source outage is never reported as healthy — it shows as unknown, on the API, the CLI, and the console, every time.
The Google SRE Workbook method — a condition only fires when both a long and a short window agree the burn is real, so a spike that's already stopped doesn't keep paging. Alerts route through the on-call schedules and escalation policies you already run in Veirox.
The arithmetic
This is the exact math Veirox runs on every tick — no black box.
The budget
A 99.9% availability target over a rolling 30-day window allows
43m 12s
of unavailability across the whole window — the entire error budget.
The burn
Burning at 14.4× the sustainable rate consumes
2%
of that 30-day budget in a single hour. That's the burn rate Veirox's fastest alert condition is tuned to catch — paging well before the budget is gone, not after.
The differentiator
Your network
Prometheus
no public address, no inbound rule
outbound-only tunnel →
raw response crosses, then is discarded
Your instance
SLI + budget
only the computed aggregates are stored
Veirox queries your Prometheus — direct, or through an existing Veirox Connect connector when it has no public address and no inbound firewall rule at all. Either way the raw response comes back to your own instance, is converted into good/total counts, and is discarded — nothing raw is ever written to disk. Only the computed figures Veirox derives from that response are persisted, in your own self-hosted instance. Datadog is reached directly the same way any SaaS API is, with its API and application keys held in your instance's secrets vault, never in the objective's config.
Fits what you already run
On-call & paging
A burn alert is an ordinary Veirox alert — it routes through the on-call schedules and escalation policies you already configured, or out to PagerDuty or Opsgenie if that's what your team pages from.
Acknowledge from chat
Acknowledge, resolve, or snooze a burn alert from Slack, Telegram, or a one-click link in the email — the same lifecycle the console and API use, so every action is audited with which channel it came from.
Agent investigation attached
A burn alert can open an agent session automatically — what changed, the health of the metric source, which runbook applies — so the first minutes of a page are spent deciding, not gathering context.
Gate CI on the budget
veirox slo check --service checkout-api --fail-on at_risk exits non-zero when a budget is running low — wire a deploy pipeline to it without a bespoke API client.
SLOs as code
Export and import objectives as OpenSLO — the vendor-neutral YAML spec — so targets are reviewed in a pull request next to your Helm charts, and veirox slo apply converges them from git the way you already converge infrastructure.
Self-hosted, on your own infrastructure. Install it, register a service, and see a real budget on the first evaluation cycle.